Skip to main content
Quick summary
Suki provides a webhook endpoint so your application can be notified when ambient sessions complete or fail. You configure a callback URL. When an event occurs, Suki sends a POST request to that URL. Suki supports push and pull mechanisms based on partner requirements for notifications.
Last updated:June 2026
Notification webhook is supported by: APIs. Web SDK, Mobile SDK, and Headless Web SDK use the same platform APIs for sending notifications.
Suki for Partners provides a endpoint so your application can be notified when ambient sessions complete or fail. You configure a callback URL. When an event occurs, Suki sends a POST request to that URL. This guide explains how webhooks work and how push compares to pull. Suki supports both push and pull based on partner requirements. This guide focuses on push (webhooks). It also covers how the capability applies across APIs and SDKs and how to implement and secure your webhook endpoint.

​
Push vs pull

Notifications can be delivered in two main ways:
  • Pull: Your application repeatedly asks Suki whether something has changed (for example, Polling the Session Status endpoint). Your system is responsible for when and how often to check.
  • Push: Suki sends a request to your application when an event happens. Your application exposes an endpoint that Suki calls; you do not need to poll.
Suki supports both push and pull based on partner requirements. When you choose to use push mechanism, Suki sends a single POST request to a callback URL that you provide when a session completes, fails, times out, or is cancelled.
With push mechanism, you host the callback URL and the infrastructure that receives the notification.Suki does not store or queue notifications; delivery is one-way and immediate.

​
Notification capability across all offerings

Webhook notifications are part of the Suki Developer Platform APIs. You register a webhook callback URL at the partner level during onboarding; that URL is used for all sessions created under your partner account.
The Web SDK, Mobile SDK, and Headless Web SDK all use the same notification webhook for sending notifications to your callback URL.
When a session is started and ended from any of these clients, the same platform backend processes it and sends the webhook notification to your callback URL.
We configure one webhook URL per partner. That single URL receives all webhook notifications for your organization, whether the session was created with the direct API, Web SDK, Mobile SDK, or Headless Web SDK. You do not need a separate URL for each client to receive notifications.

​
Guides

Quickstart

Step-by-step setup: prerequisites, implement your endpoint, verify, and test.

Payload & Response

Payload structure, example JSON, implementation tips, and follow-up API responses.

Signature Verification

Verify HMAC-SHA-256 signatures with your partner secret key before you trust the body.

Configuration

Register your callback URL during onboarding and meet endpoint requirements.

Event Types

Session completion, failure, timeout, and cancellation events your endpoint receives.

​
API reference

To view and implement your webhook endpoint, refer to the Asynchronous notifications (webhook) API reference.
Last modified on June 12, 2026