OpenRelay is happy to announce that we now support the Standard Relayer API’s Websockets specification. If you are working with a tool that already supports this specification, you can connect to OpenRelay at wss://api.openrelay.xyz/v2/ws

Pools

We’ve previously discussed OpenRelay Pools, and our Websockets API works within pools. For example, if you connect to wss://api.openrelay.xyz/feefree/v2/ws it will provide information about orders in the feefree pool.

Extensions

OpenRelay implements a bit above and beyond the Standard Relayer API.

Response Data

As in our implementation of the HTTP Specification of the Standard Relayer API, the metaData field of each record includes:

hash - The hash of the 0x order

- The hash of the 0x order feeRate - The number of ZRX tokens the taker must pay per base unit of the taker asset.

- The number of ZRX tokens the taker must pay per base unit of the taker asset. status - OpenRelay’s internal status code for the order.

The Websockets API will not include ERC721 metadata.

Filter Options

The standard Websockets API is fairly limited on what order attributes you can specify in order filters. With OpenRelay, you can filter on any attributes you could use to filter on the /v2/orders endpoint.

Other Notes

In general, OpenRelay strives for high-availability of our services. Our systems are architected to allow seamless scaling up and down of our HTTP services and our order validation pipeline, as well as performing upgrades without any downtime. With HTTP services, we simply need to ensure that there is always a service available to process a request. With our validation pipeline, we can stand up new validation services before taking the old one down, and all of the messages get queued in our messaging service. With websockets, however, it is impossible for us to restart our websocket services without disrupting active connections. It should always be possible for you to immediately establish a new connection upon disconnection, but eventual disconnections are unavoidable. While we hope websockets disconnections will be few and far between, we strongly advise you build your applications to account for the eventuality of a websockets disconnection. Your application will need to reconnect to the websockets endpoint and resubscribe to any filters.