E/M Coding Webhook Overview

Understand when Suki sends standalone E/M Coding webhooks, how to interpret session outcomes, and how to retrieve the codes

E/M Coding webhooks notify your application when Suki finishes coding a note. Your application can use the notification to check the session status and retrieve the recommended visit codes without repeatedly polling the API.

During partner onboarding, Suki configures a callback URL for your account. Suki sends notifications to this URL when a standalone E/M Coding session completes, fails, or is aborted.

The webhook contains the processing outcome, session identifiers, and links to the available results. It does not contain the codes themselves. Your application must retrieve that content through the API.

• This webhook is only for standalone E/M Coding, where you send finished note content yourself.

• When you ask for E/M codes on an ambient visit with artifacts: ["EM_CODES"], Suki does not send this webhook. Instead, the Ambient webhook for that visit includes em_codes and encounter_em_codes links. To compare the two paths, refer to Choose ambient or standalone.

​

Common use cases

Use the E/M Coding webhook when you want your application to react as soon as standalone coding finishes, instead of polling for status.

Show Codes for Review

When the notification reports SUCCESS, load the recommended codes and their reasons into your coding review UI.

Advance RCM Workflows

Move a visit into your billing or review queue as soon as the codes are ready.

Stop Polling for Status

Replace repeated status calls with a single push notification for each standalone coding session.

Catch Failures Early

When the notification reports FAILURE, log error_code and error_detail so coding staff and operations see accurate session status.

​

When Suki sends an E/M Coding webhook

Suki sends an E/M Coding webhook after you call Generate E/M codes and coding reaches a final outcome. This includes successful coding, coding failures, and aborted sessions.

Suki does not send a webhook while coding is still running.

The top-level status indicates the outcome reported by the notification:

Session outcome	Webhook status	What your application should do
Coding completed	SUCCESS	Check the session status. Read the recommended codes from the em_codes link.
Coding failed	FAILURE	Record error_code and error_detail. Alert or show an error.
Session aborted	FAILURE	Handle the notification as a failed session.

​

Delivery rules

Your webhook receiver must account for the following behaviors:

• Only the final outcome is sent. Suki sends nothing while coding is still running.
• A FAILURE notification does not always mean coding failed. If error_code is ERROR_CODE_NOTIFICATION_GENERATION_FAILURE, Suki could not generate the webhook body. Coding itself may have finished successfully. Check the session status before reporting a processing error.
• The same notification can be delivered more than once. Use session_id and status to identify and skip notifications your application has already processed.

Use the webhook as a signal to check the session, not as confirmation that codes are ready to show. Call Get E/M Coding status and show codes to coding staff only after coding has finished.

If you suspect that you missed a notification, call the same endpoint to check the session’s current status.

For delivery behavior shared by all Suki webhooks, refer to Delivery rules.

​

How an E/M Coding webhook works

The following sequence shows how Suki delivers a notification and how your application retrieves the results.

1. Send the Note for Coding

   Your application calls Generate E/M codes with the finished note content and saves the session_id from the 201 response.

2. Suki Codes the Visit

   Suki reviews the note and recommends Evaluation and Management codes with the reasons behind them.

3. Suki Sends the Webhook

   Suki sends a POST request to your configured callback URL. The request contains the processing outcome and the E/M session_id.

4. Verify the Request and Respond

   Your endpoint verifies the webhook signature and returns HTTP 200 within 30 seconds. Refer to Signature verification.

5. Check the Status and Retrieve Codes

   When the notification reports SUCCESS, call the status link if you need to confirm coding finished, then call the em_codes link to read the recommended codes. Refer to Retrieve E/M Coding results.

​

What makes this payload different

The E/M Coding payload uses the same status pattern as Ambient and Form filling, with a few differences you should plan for:

• session_id is the E/M Coding session ID from Generate E/M codes. It is never an ambient session ID.
• Standalone E/M Coding sessions are not tied to an encounter, so encounter_id is present but empty. Do not use it to look up the visit. Store your own visit reference next to the session_id when you call Generate E/M codes.
• sessions contains only the one E/M Coding session.
• _links contains only status and em_codes. Every other key is present but empty.

Generated codes stay available for 30 days. Read them soon after the webhook arrives and store what you need.

​

Next steps

E/M Coding payload reference - Every field in the success and failure payloads.

Retrieve E/M Coding results - Read the codes and session status.

Generate standalone E/M codes - Send a finished note for coding.

E/M Coding asynchronous notifications - OpenAPI specification and sample handlers.