GET /events replay endpoint.
Event types
status_changed is the single lifecycle signal: a completed payment is status_changed with status: "completed", and a freshly deployed wallet rides on the status_changed into pending_swap (carrying its deploy txHash).
Socket.IO
The live stream is served over Socket.IO (bun add socket.io-client). Connect to the base URL and pass your API key in the handshake auth:
connected event with your integrator name:
GET /events.
deposit_detected
queued tells you whether the deposit entered the settlement queue. If false, ignoredReason explains why (below_token_min, below_min, no_adapter, enqueue_error), so a dust/spam deposit that will never produce a swap is an explicit signal, not a detection with no follow-up. below_token_min is the per-token minimum (see GET /source-config); below_min is the chain-level USD floor.
status_changed
queueItemIdis the settlement id (matchesGET /swapsid).errorisnullexcept on failing/deferred states (see the error model).txHashcarries the wallet-deployment tx on the transition intopending_swap, and the swap/settle tx on the transition intocompleted.- To react only to final outcomes, filter on
terminal: true(completed= success,dead= failure).
Delivery and replay
Socket.IO fan-out is live and best-effort: events are pushed only to currently-connected sockets and are not buffered per connection. Socket.IO auto-reconnects, but events that fired while you were disconnected are not resent. Catch up with the replay endpoint rather than relying on the socket.since (omit since to start from the oldest retained event). Page forward with nextCursor until it is null.
Events are retained for 30 days and pruned afterwards, so replay only reaches back over the retention window. Treat events as idempotent: dedupe on the event
id (from GET /events), or on data.queueItemId + data.status.