> ## Documentation Index > Fetch the complete documentation index at: https://developer.eka.care/llms.txt > Use this file to discover all available pages before exploring further. # Webhooks > Every event ABDM Connect sends to your server, when it fires, and which workflow handles it. 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](https://developer.eka.care/api-sdk/webhooks/getting-started.md) and [Register a webhook](https://developer.eka.care/api-sdk/webhooks/register-webhook.md). The [PHR webhooks guide](https://developer.eka.care/docs/hie-cm/phr/webhooks.md) 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](https://developer.eka.care/api-sdk/webhooks/register-webhook.md). ### 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](https://developer.eka.care/docs/webhooks/webhook-signature.md) 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. * Payload: [ABHA Address Created](https://developer.eka.care/docs/hie-cm/webhooks/abha-created.md) * Consumed by: [Create an ABHA with Aadhaar OTP](https://developer.eka.care/docs/hie-cm/workflows/create-abha-aadhaar-otp.md), [Create an ABHA address with mobile OTP](https://developer.eka.care/docs/hie-cm/workflows/create-abha-mobile-otp.md), [Create an ABHA with face authentication](https://developer.eka.care/docs/hie-cm/workflows/create-abha-face-auth.md) ## Health Information Provider (HIP) ### `abha.link_care_context` Fires after you call the [Care Context Link API](https://developer.eka.care/api-sdk/hie-cm/care-contexts/link/hip-linking.md), with the result. `data.status` is `LINKED` when the care context is registered with ABDM, or `ERRORED` with the reason in `data.error`. * Payload: [Care Context Linking Status](https://developer.eka.care/docs/hie-cm/webhooks/link-care-context.md) * Consumed by: [Link a care context as a HIP](https://developer.eka.care/docs/hie-cm/workflows/link-care-context-hip.md) ### `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](https://developer.eka.care/api-sdk/hie-cm/care-contexts/discover/on_discover.md). * Payload: [Discovery Request Received](https://developer.eka.care/docs/hie-cm/webhooks/discover-care-context.md) * Consumed by: [Answer discovery and link old records](https://developer.eka.care/docs/hie-cm/workflows/hip-discovery-and-link.md) ### `abha.care_context_discover_link_init` Fires when the patient chooses which discovered records to link. Generate an OTP, send it to the patient, and call [On Link Init](https://developer.eka.care/api-sdk/hie-cm/care-contexts/discover/link_on_init.md). * Payload: [Link Initiation - Generate OTP](https://developer.eka.care/docs/hie-cm/webhooks/discover-link-init.md) * Consumed by: [Answer discovery and link old records](https://developer.eka.care/docs/hie-cm/workflows/hip-discovery-and-link.md) ### `abha.context_discover_link_confirm` Fires when the patient submits the OTP. Check it against the OTP you sent, then call [On Link Confirm](https://developer.eka.care/api-sdk/hie-cm/care-contexts/discover/link_on_confirm.md) with the care contexts to link. * Payload: [Link Confirmation - Verify OTP](https://developer.eka.care/docs/hie-cm/webhooks/discover-link-confirm.md) * Consumed by: [Answer discovery and link old records](https://developer.eka.care/docs/hie-cm/workflows/hip-discovery-and-link.md) ### `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](https://developer.eka.care/api-sdk/hie-cm/care-contexts/data-on-fetch.md). * Payload: [Health Data Requested by HIU](https://developer.eka.care/docs/hie-cm/webhooks/hip-data-fetch.md) * Consumed by: [Serve records on a fetch request](https://developer.eka.care/docs/hie-cm/workflows/serve-data-on-fetch.md) ### `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. * Payload: [Scan and Share Token Received](https://developer.eka.care/docs/hie-cm/webhooks/hip-scan-and-share.md) * Consumed by: [Receive a scanned profile as a HIP](https://developer.eka.care/docs/hie-cm/workflows/hip-scan-and-share.md) ## Health Information User (HIU) and consent ### `abha.consent_update` 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. * Payload: [Consent Update](https://developer.eka.care/docs/hie-cm/webhooks/consent-update.md) * Consumed by: [Request a patient's consent as a HIU](https://developer.eka.care/docs/hie-cm/workflows/hiu-request-consent.md), [Approve, deny or revoke a consent in a PHR app](https://developer.eka.care/docs/hie-cm/workflows/phr-act-on-consent.md) ### `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. * Payload: [Health Data Received from HIP](https://developer.eka.care/docs/hie-cm/webhooks/hiu-data-push.md) * Consumed by: [Receive and decrypt records as a HIU](https://developer.eka.care/docs/hie-cm/workflows/hiu-receive-data.md) ## Health locker ### `abha.locker_created` Fires when a health locker is set up. Store `data.auto_approval_id` and `data.subscription_id`. * Payload: [Locker Created](https://developer.eka.care/docs/hie-cm/webhooks/locker-created.md) * Consumed by: [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) ### `abha.subscription_notify` Fires when a HIP links a new care context to an ABHA address you hold an active subscription for. * Payload: [New Care Context Linked (Subscription)](https://developer.eka.care/docs/hie-cm/webhooks/subscription-notify.md) * Consumed by: [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) ### `abha.subscription_modified` Fires whenever a subscription is updated. * Payload: [Subscription Updated](https://developer.eka.care/docs/hie-cm/webhooks/subscription-modify.md) * Consumed by: [Set up the patient's health locker](https://developer.eka.care/docs/hie-cm/workflows/set-up-health-locker.md) ## 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](https://developer.eka.care/api-sdk/uhi/phys-cons/search-doctors.md). * Payload: [Search Doctors](https://developer.eka.care/docs/uhi/webhooks/search-doctors.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) ### `doctor.slot.search.results` Fires with the results of a doctor's consultation slot search, [Search Slots](https://developer.eka.care/api-sdk/uhi/phys-cons/search-slots.md). * Payload: [Search Slots](https://developer.eka.care/docs/uhi/webhooks/search-slots.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) ### `booking.init` Fires with the result of [Init](https://developer.eka.care/api-sdk/uhi/phys-cons/init.md): the quote, terms and payment details. * Payload: [Booking Init](https://developer.eka.care/docs/uhi/webhooks/booking-init.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) ### `booking.confirm` Fires with the result of [Confirm](https://developer.eka.care/api-sdk/uhi/phys-cons/confirm.md): the booking confirmation and its details. * Payload: [Booking Confirm](https://developer.eka.care/docs/uhi/webhooks/booking-confirm.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) ### `booking.status` Fires with the result of [Order Status](https://developer.eka.care/api-sdk/uhi/phys-cons/order-status.md): the booking's status and details. * Payload: [Booking Status](https://developer.eka.care/docs/uhi/webhooks/booking-status.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) ### `booking.cancel` Fires when a booking cancellation requested through [Cancel](https://developer.eka.care/api-sdk/uhi/phys-cons/cancel.md) completes. `data.status` carries the result. * Payload: [Booking Cancel](https://developer.eka.care/docs/uhi/webhooks/booking-cancel.md) * Consumed by: [Book a physical consultation over UHI](https://developer.eka.care/docs/uhi/workflows/uhi-book-consultation.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.