Skip to main content
Watch the order until it reaches COMPLETED, ERROR, or TIMED_OUT; every status is defined in the order lifecycle.

Polling

GET /v1/orders/{uuid} returns the full order with no headers; the UUID authorizes the read. Poll every 5 seconds, since transitions wait on block confirmations anyway. An unknown UUID returns 500, not 404, so cap failures and check the UUID against your records before assuming an outage.

SSE

The status stream pushes one orders:status-update event per transition. It sends no initial event, so subscribing tells you nothing about where the order stands; fetch the order first, every time. Events carry only {orderId, status, message, updatedAt}, with the UUID as orderId, which makes each one a cue to re-fetch.

Reconnect and fallback

Streams drop, and the server itself closes any stream that has been silent for 60 seconds, so over a 30 minute deposit window you reconnect about 30 times. Reconnect to the same URL and re-fetch the order before trusting new events, because missed transitions are never replayed. EventSource reconnects on its own after the 5 second retry delay, and putting the re-fetch in onopen covers every reconnect in one place. Raw HTTP clients need an explicit loop: reopen the stream whenever it closes, with a read timeout above 60 seconds so the server always closes first. Keep a slow poll running underneath the stream, and shut everything down once a fetch shows a terminal status.