Skip to main content

​
Realtime events

The Platform API is poll-based today. Most long-running operations return 202 Accepted with a _links poll target; a few async surfaces use a different shape (a hosted widget, or a dedicated status endpoint). There is no partner-facing realtime event bus yet.

​
What to do today

Asynchronous operations fall into three patterns. Match each operation to the right one rather than assuming everything is 202-and-poll. Safe deployment or an (IPA) preflight: you receive a 202 Accepted with the resource snapshot and a _links.self poll link. Poll the linked resource until its terminal state is reached. Cadence is up to you; most operations complete in 10–30 seconds. The API conventions page has the full 202 pattern.

​
Hosted widget

An ramp session (POST /v0/ramp/sessions) returns 201 Created with a widget_url. Render it in an iframe or webview and listen for the provider’s postMessage completion event; poll GET /v0/ramp/transactions for final settlement. See the On-ramp quickstart.

​
Status endpoint

KYC processing (which feeds ) is not a 202 operation. Start verification with the Sumsub Web SDK, then poll GET /v0/kyc/status — use ?refresh=true to force a live pull — until a terminal state. Approval arrives via an internal webhook roughly 30–60 seconds after submission. See the KYC guide.

​
What is not yet exposed

Sumvin runs an internal SSE bus for the Sumvin consumer app (chat sessions, workflow runs, agent todos). That bus is 1p-only and is not part of the partner API surface — it won’t appear in your integration. Sumvin also consumes inbound webhooks from its identity-verification and on/off-ramp providers. Those are consumed internally to advance the user’s state; they are not re-emitted to partner webhooks today. A partner-facing realtime surface (SSE or webhooks) is not part of the API today. Build against the patterns above.

​
See also

​
Referenced from