Skip to main content
Early access. Guaranteed delivery is live in production, but no solver has exercised it yet. It should behave as described. If you see missing messages, duplicate floods, or subscribe errors, let us know in the shared support channels.
Guaranteed delivery lets your solver recover quote_status events it would otherwise miss while disconnected. The quote_status stream notifies your solver when one of its quotes is executed, carrying quote_hash, intent_hash, and tx_hash. Without guaranteed delivery, any event published while your WebSocket is disconnected is lost. With it, the relay keeps a server-side queue for each solver instance. Events wait while you are offline, then replay when you reconnect, for up to 7 days.

Opt in

Guaranteed delivery requires an authenticated solver connection (JWT). Complete these three steps:
1

Add instance_id to the WebSocket URL

Connect with an instance_id query parameter:
The relay finds your queue by this ID on every reconnect, and creates it the first time you subscribe with the guaranteed flag.Use a fixed value from your deploy config (prod-1, prod-2), not a random one generated at startup.IDs are scoped to your solver account, so two solvers using the same instance_id never collide. The relay gives each one a separate queue:
  • Use the same value across restarts and reconnects. A new value gives you a new, empty queue.
  • One value per instance. Two instances sharing an ID fight over one queue, and each message goes to only one of them, chosen arbitrarily.
  • One live connection per ID. Don’t open two at once for redundancy.
2

Subscribe with the guaranteed flag

Open the WebSocket with your instance_id, then send a subscribe request for quote_status. Set the third positional parameter to true; the second parameter (filters) must be empty.
The response returns your subscription ID:
The request is rejected without an authenticated Partner JWT and the instance_id from Step 1.
If you already subscribe to quote_status, this replaces that call.
3

Handle and acknowledge every message

Messages arrive as event notifications carrying a seq:
Handle each event by acknowledging it with your subscription ID and its seq, then running your settlement logic:
Acknowledge first, process second. Redelivery fires after 5 seconds, which is too short for settlement logic. Persist or queue the message locally, acknowledge it, then do the work.
Deduplicate by seq or quote_hash. Redeliveries happen on reconnect, so you will sometimes receive the same message twice.

After a reconnect

A subscription only lasts as long as the connection it was created on. When you reconnect, that old subscription is gone, so you have to send subscribe again. Doing so gives you a new subscription ID, and from that point on your acks must use the new ID, not the old one. As soon as you re-subscribe, the relay replays your backlog in one burst: every message published while you were offline, plus any messages it had already sent you but that you hadn’t acknowledged before the connection dropped. Wrap the connection in a function so a drop reconnects and re-subscribes on its own. This reuses handleMessage from Step 3, and keeps seen across reconnects so the replayed backlog is still deduplicated:

Limits


Errors

Subscribe rejected

Acknowledge