Skip to main content
ABDM is asynchronous. Many results never come back on the request you made. Eka sends them to your webhook endpoint as events. This page lists all 18 ABDM Connect events. Each event’s own page carries its payload.

​
In short

  • Eka sends results that do not come back on your request to your webhook endpoint as events.
  • Your endpoint is a public HTTPS URL that accepts POST requests.
  • Every event has the same envelope; the fields inside data differ per event.
  • Verify Eka-Webhook-Signature with HMAC-SHA256 when you gave a signing key.
  • Reply 200 within 5 seconds, then do the work.

​
Delivery, signature and acknowledgement

​
Registering your endpoint

Your endpoint is a public HTTPS URL that accepts POST requests. See Getting started with webhooks and Register a webhook. The PHR webhooks guide says there is no self-service API to register an ABDM webhook URL, and that you share your endpoint with Eka (console or support) before sandbox testing. If your network restricts inbound traffic, allowlist Eka’s production and staging IP addresses listed on Register a webhook.

​
What every request carries

Every event is a POST with two headers:
  • Content-Type: application/json
  • Eka-Webhook-Signature: present when you gave a signing key at registration
The body has the same envelope for every event: service, event (the event name), event_time, transaction_id, timestamp, business_id, client_id, and data. The fields inside data differ per event; see each event’s page.

​
Verifying the signature

Eka signs the payload when you provide a signing key while registering the webhook. Without a key, Eka still sends the event, unsigned. You can use one key for all webhooks or a unique key per webhook. The ABDM Connect spec marks Eka-Webhook-Signature as required on every event, so whether Eka ever delivers an unsigned event is not yet confirmed. The header has the form t=TIMESTAMP,v1=SIGNATURE. To verify it:
  1. Read t and v1 from Eka-Webhook-Signature.
  2. Compute an HMAC-SHA256 over TIMESTAMP.PAYLOAD with your signing key.
  3. Compare your result with v1. If they match, the event came from Eka and was not changed.
To block replayed events, reject a request whose t is older than your tolerance, for example 3 minutes. Webhook signature has example code.

​
Acknowledging

Reply 200 within 5 seconds. Eka retries on any other status. Reply first, then do the work: decrypting records, building FHIR bundles or calling back Eka.

​
ABHA

​
abha.created

Fires when an ABHA address is created. Provision the patient in your database from this event, not only from the API response.

​
Health Information Provider (HIP)

Fires after you call the Care Context Link API, with the result. data.status is LINKED when the care context is registered with ABDM, or ERRORED with the reason in data.error.

​
abha.care_context_discover

Fires when a patient asks your facility, from a PHR app, for records not yet linked to their ABHA. Search your system with the details in data and answer with On Discover. Fires when the patient chooses which discovered records to link. Generate an OTP, send it to the patient, and call On Link Init. Fires when the patient submits the OTP. Check it against the OTP you sent, then call On Link Confirm with the care contexts to link.

​
abha.hip_data_fetch

Fires when a Health Information User (HIU) requests data for care contexts you linked. You receive it only if you do not store the health data on Eka. Encrypt the FHIR bundles with the key_information in the payload and push them with Care Context Data On-Fetch.

​
abha.hip_profile_share

Fires when a patient scans your facility’s QR code with a PHR app and shares their ABHA profile for an OPD token. data.hip_code is the counter id. Fires whenever a consent changes, with the updated details. Expect it more than once for the same consent request; treat the latest status as current.

​
abha.hiu_data_push

Fires when a HIP pushes encrypted health data for a consent you raised. You receive it only if you manage the data on your side.

​
Health locker

​
abha.locker_created

Fires when a health locker is set up. Store data.auto_approval_id and data.subscription_id.

​
abha.subscription_notify

Fires when a HIP links a new care context to an ABHA address you hold an active subscription for.

​
abha.subscription_modified

Fires whenever a subscription is updated.

​
Unified Health Interface (UHI) bookings

Each UHI call starts a request and returns at once. The result arrives on one of these events. You can also read it with the matching GET.

​
doctor.search.results

Fires with the results of Search Doctors.

​
doctor.slot.search.results

Fires with the results of a doctor’s consultation slot search, Search Slots.

​
booking.init

Fires with the result of Init: the quote, terms and payment details.

​
booking.confirm

Fires with the result of Confirm: the booking confirmation and its details.

​
booking.status

Fires with the result of Order Status: the booking’s status and details.

​
booking.cancel

Fires when a booking cancellation requested through Cancel completes. data.status carries the result.