Versioning
Pin dated REST and WebSocket API versions so contract changes are explicit and your integration behaves consistently over time.
UDX publishes dated contracts. Each API has its own version selector and selection lifetime, and a version never changes once published.
| Interface | Version selector | Selection lifetime |
|---|---|---|
| REST | UDX-Version request header, echoed on every response |
One request |
| WebSocket | Sec-WebSocket-Protocol during the HTTP Upgrade |
One connection |
Set a version explicitly after testing your integration against its contract, and test against the new contract before changing it.
Every version that UDX still supports has its own API reference. Use the API version selector at the top of the REST or WebSocket reference to read the contract for the version you send. The changelog records what each version changed.
Select a Version
Send a version published in the OpenAPI specification:
UDX-Version: <YYYY-MM-DD>If you omit this header, the exchange uses the oldest supported REST version. An integration that omits the header will not adopt a newer contract automatically.
Every response includes the applied UDX-Version. An unsupported value returns 400 and lists the supported versions.
Select a subprotocol published in the AsyncAPI specification when opening the connection:
Sec-WebSocket-Protocol: udx.json.<YYYY-MM-DD>The selected subprotocol sets the command and message contract for that connection. WebSocket frames do not carry a version header. To change versions, close the connection and reconnect with another supported subprotocol.
Most WebSocket clients accept the subprotocol as a connection option. Use the exact value published in AsyncAPI.