_links to follow.
Unlike Ambient, Form filling, and standalone E/M Coding webhooks, CKG ingestion puts the outcome in
state and includes any error details in the body. Match the transaction_id to the upload you started, then act on the state.state first. When it is COMPLETED, start Patient Summary generation for the encounters in the bundle. When it is FAILED or ABORTED, use the error object, when present, to decide whether to upload again or fix the bundle first.
Prerequisites
Before you handle results, make sure you have:- A webhook receiver: An endpoint that receives Suki webhooks and verifies their signatures. Refer to Webhook quickstart and Signature verification.
- Saved upload IDs: Store the
transaction_idreturned by Request FHIR bundle upload URL for each upload, and thecorrelation_idif you sent one.
Match the webhook to your upload
When you request an upload URL, store the returnedtransaction_id with your own record of the upload, such as the patient, the encounter, and when you uploaded. When the webhook arrives, look up that record by transaction_id.
correlation_id helps when you group several uploads under one reference of your own, such as a batch or sync run. Send it as a query parameter when you request the upload URL, up to 128 characters. If you leave it out, Suki generates one and returns it in the webhook.
Handle results step by step
Follow this sequence after your webhook endpoint receives a CKG ingestion notification:Verify the Webhook and Return HTTP 200
Verify the webhook signature and return HTTP 200 within 30 seconds. Do not wait for Patient Summary generation or a new upload to finish before you respond. Process the notification in a background job.
Match the Transaction ID
Look up your saved upload record with
payload.transaction_id. If the ID is unknown, log it and stop. Do not start Patient Summary generation for an unmatched upload.Read the State
Branch on
payload.state. CKG payloads use state, not status. A CKG payload never includes a status field.Act on the Outcome
Generate summaries, retry the upload, or flag the bundle for review based on the state and, when present, the
error object.Act on each state
The matching polling status is what Check ingestion status returns for the same job. The webhook reports an archived upload as
ABORTED.
The
error object appears only when state is FAILED or ABORTED, and only when Suki recorded an error for the job. Do not assume it is always present. When FAILED has no error object, treat the failure as not retryable and investigate.Example: handle CKG ingestion states
The following examples run after your webhook endpoint has verified the signature and returned HTTP 200. They:- Match
transaction_idto a saved upload record. - Branch on
state. - Call your own helpers to generate summaries, upload again, or flag a bundle for review.
start_patient_summaries, upload_again, and flag_for_review stand in for your application logic.
Code example
- Python
- TypeScript
- Go
Use polling as a fallback
If a webhook does not arrive, for example because your endpoint was down longer than Suki retries, call Check ingestion status with thetransaction_id. Status stays available for 7 days after the upload. A polling status of ARCHIVED is the same outcome as a webhook state of ABORTED.