Skip to main content
When an ambient session reaches a final processing outcome, Suki sends a success or failure payload to your configured callback URL. Read the top-level status field to identify the payload type:
  • SUCCESS: Suki finished processing the session. This includes sessions where processing was skipped because the recording was silent or too short.
  • FAILURE: Processing failed or the session was aborted.
Each payload contains the session and encounter identifiers. A success payload also contains an _links object with links to retrieve session-level and encounter-level results. A failure payload contains an error code and description instead.

Success payload

Suki sends a success payload when ambient processing finishes. This includes cases where processing was skipped because the recording was silent or too short.
The success payload always uses this notification shape.
  • Every _links key is present.
  • What each link returns depends on how you ran the session: the patient, visit, diagnoses, Medication orders, sections, and artifacts you seeded when you created or updated the session; whether you streamed live audio, uploaded a recording, or submitted a finished transcript; and what was available from the visit.
  • Empty values lists are normal when that data was never produced. A dedicated guide for audio-file and transcript sessions is coming later.

Fields

string
required
Always SUCCESS.
string
required
Identifier of the ambient session that triggered this notification.
string
required
Identifier of the encounter associated with the ambient session.
array of strings
Identifiers of all ambient sessions in the encounter so far, ordered from oldest to newest. This list includes the session identified by session_id.
object
Additional context about the notification.
Links to the resources available for the encounter. Every key is present in the object. When a key has no links to return, its value is an empty array.Refer to The _links object for the complete list of keys and their descriptions.

Example success payload

This example shows an encounter containing two ambient sessions. The session_id identifies the second session in the sessions array. Session-level link arrays contain one link for each session, in the same order as the sessions array. Encounter-level link arrays contain one link for the entire encounter.
The _links object contains the API paths your application can call to retrieve session and encounter results. Each key contains an array of link objects. Every link object has the same four fields: Session-level link arrays contain one link for each session in sessions, in the same order. Use the link’s name to identify the session whose results you want to retrieve. Encounter-level link arrays contain one link for the entire encounter. These resources return encounter-level results rather than separate results for each session.
Make your webhook parser ignore unrecognized keys in _links. This allows your integration to handle new link types added in future releases without breaking the webhook handler.

Failure payload

Suki sends a failure payload when ambient processing fails or when a session is aborted. Unlike the success payload, the failure payload does not contain sessions, _links, or additional_info. Instead, it includes an error code and a description of the error.

Fields

string
required
Always FAILURE.
string
required
Identifier of the ambient session that failed or was aborted.
string
required
Identifier of the encounter associated with the session.
string
required
Machine-readable code that identifies the reported error. Refer to Error codes.
string
required
Human-readable description of the error. This field can contain an empty string when Suki has no additional details.

Example failure payload

A failure payload does not contain additional_info, so it does not identify the product through session_type.If multiple Suki products send notifications to the same callback URL, match session_id against the ambient session IDs your application saved when it created the sessions.

Error codes

The error_code field identifies the type of error reported in the failure notification. Use error_code to identify and handle error conditions in your application. Log error_detail to help with troubleshooting or to provide context when notifying your team or clinician.
Do not use error_detail as the basis for application logic. Its wording can change. Use error_code for programmatic error handling.

Next steps

Retrieve ambient results - Build API requests from _links and retrieve session and encounter results. Ambient webhook overview - When Suki sends Ambient webhooks and how to handle each outcome. Webhook event catalog - Payload references for other Suki products. Ambient asynchronous notifications - OpenAPI specification and sample handlers.
Last modified on November 5, 2026