WebSocket /route/subscribe
This page is also Markdown, for agents: /dex-aggregator/reference/subscribe.md, and /llms.txt lists every page.
wss://router.intear.tech/route/subscribeA WebSocket that sends quotes for a request and keeps sending new ones as pools change. See Live quotes for a walkthrough.
Connection
Section titled “Connection”All messages are JSON in text frames. Non-text frames from the client are ignored. Add ?key=<api key> to the URL to lift the rate limit.
The server never sends a WebSocket close frame, so clients see every close, including one they start, as abnormal (code 1006). Don’t use the close code to tell why a connection ended.
Client messages
Section titled “Client messages”{ "id": 1, "query": "token_in=near&token_out=nep141:usdt.tether-token.near&amount_in=1000000000000000000000000&slippage_type=Fixed&slippage=0.01" }| Field | Type | Description |
|---|---|---|
id |
unsigned integer | Your ID for this request, sent back with each update |
query |
string, optional | Same query string as GET /route. If missing, the current request is stopped and nothing new starts |
Each message replaces the previous request. A message that isn’t valid JSON of this shape, including one whose id is negative, fractional, a string or missing, makes the server drop the connection.
Server messages
Section titled “Server messages”Quotes for a request:
{ "id": 1, "routes": [ ... ] }routes is an array of quote objects, best first, same as GET /route. The first update is sent after the first round of routing, with an empty routes array if no DEX found a route. After that, one is sent each time pools update and the quotes change.
An error for a request:
{ "id": 1, "error": "Slippage must be between 0.00 and 1.00" }Sent instead of quotes when the query is invalid. The connection stays open. Validation errors have the same text as for GET /route. Errors in parsing the query string come without the Failed to deserialize query string: prefix and the parameter name, like missing field `token_in` or Empty dex id.
Timing
Section titled “Timing”After each round of routing, the server waits until about 10× the routing time has passed since the round started, at most 3 seconds. Then it routes again as soon as any pool has changed since the round started. In practice this means an update every block or every few blocks while the pools are active.