Skip to main content
Every order can be followed to a terminal state by polling, over SSE, or both at once. Polling GET /v1/orders/{uuid} returns the full order with no credentials; the UUID alone is the read key. Every 5 seconds is plenty, since transitions wait on block confirmations anyway. The stream pushes an orders:status-update event on each change, carrying only {orderId, status, message, updatedAt} with the UUID as orderId, so treat every event as a cue to re-fetch the order.
The order of those two calls matters. The stream sends no initial event, so fetch first, subscribe after, and re-fetch on every reconnect. Reconnects are routine: the server closes any stream that stays silent for 60 seconds, EventSource reopens it automatically, and raw HTTP clients need a loop. The rest of the contract is on Order status stream. Use polling alone for backends and scripts. Add the stream when a user is watching a status screen and seconds matter, with a slow poll underneath as a safety net; working loops with reconnect handling are in Track orders. Either way, stop once a fetch shows COMPLETED, ERROR, or TIMED_OUT; terminal orders never change again.