7 · PHR Webhooks - Eka Developer Platform APIs

ABDM is asynchronous. Discovery results, consent decisions and new-record notifications never come back on the request you made — they arrive later, on your webhook endpoint. A PHR app that only does request/response will silently miss records.

There is no self-service API to register an ABDM webhook URL. Share your endpoint with EKA (console or support) before you begin sandbox testing.

Every payload is signed. Verify the Eka-Webhook-Signature header before trusting it — see Webhook Signature.

Identity

Event	What it means	Reference
`abha.created`	An ABHA address was successfully created. Provision the patient in your database from here rather than the client response.	ABHA Address Created

Locker & subscriptions

Event	What it means	Reference
`abha.locker_created`	Health locker set up. Carries `auto_approval_id` and `subscription_id` — store both.	Locker Created
`abha.subscription_modified`	Subscription period, categories or status changed.	Subscription Updated
`abha.subscription_notify`	A HIP linked a new care context for this patient. Metadata only — raise consent to read it.	New Care Context Linked

Event	What it means	Reference
`abha.consent_update`	A consent request changed state (granted, denied, expired, revoked).	Consent Update
`abha.hiu_data_push`	A HIP pushed the encrypted FHIR bundle you asked for. Only if you manage data yourself.	Health Data Received from HIP

Records you store yourself

Event	What it means	Reference
`rec.uploaded`	A patient-uploaded document finished processing.	Record Uploaded
`rec.refresh`	The patient’s record list changed and should be refetched.	Record Refresh

Turning events into patient notifications

Most of these events are only useful if the patient hears about them. Register the patient’s device once, and push from your cloud when a webhook lands.

Purpose	API
Register a device for push	Add Device
Remove a device	Delete Device
Configure your FCM credentials	FCM Credentials

Also HIP? Then add these

A PHR app that stores patient-uploaded records is a HIP, and if you serve that data yourself rather than letting EKA serve it, you must handle the HIP-side events too.

Event	Reference
`abha.link_care_context`	Care Context Linking Status
`abha.hip_data_fetch`	Health Data Requested by HIU
Discovery request received	Discovery Request Received
Link initiation — generate OTP	Link Initiation
Link confirmation — verify OTP	Link Confirmation
Scan & Share token received	Scan and Share Token Received

If you pass FHIR data in the data field of the Link API, or upload via the Upload API, EKA serves the data on your behalf and abha.hip_data_fetch is never sent to you.

Authorization

End-to-End Encryption

Connect

HealthAI

Medical Database

ABDM Connect

Doctor Tool

Medical Knowledge-bases

Medical Records

User App

7 · PHR Webhooks

Identity

Locker & subscriptions

Records you store yourself

Turning events into patient notifications

Also HIP? Then add these

​Identity

​Locker & subscriptions

​Consent & data

​Records you store yourself

​Turning events into patient notifications

​Also HIP? Then add these

Identity

Locker & subscriptions

Consent & data

Records you store yourself

Turning events into patient notifications

Also HIP? Then add these