OpenRelay is happy to announce that we now support the Standard Relayer API’s
If you are working with a tool that already supports this specification,
you can connect to OpenRelay at
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
OpenRelay implements a bit above and beyond the Standard Relayer API.
As in our implementation of the HTTP Specification of the Standard Relayer API,
metaData field of each record includes:
hash- The hash of the 0x order
feeRate- 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.
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
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.