webhooks
The outcome of a care context notify call you made
Hosted by your bridge, not by ABDM. The gateway calls this endpoint at the callback URL registered for your bridge, so the path above is relative to that URL. This is the result leg for m2_link_care_context_notify.
The A fresh UUID that you generate for this request. The callback that answers it carries the same value, so this is how you match an asynchronous reply to the call that caused it. Store it before you send the request, not after. The current time in ISO 8601, UTC, with milliseconds and a Identifier of the Health Information Provider the request or callback belongs to. This is per facility, and it is what a callback arriving at your one bridge URL is routed on. The bridge URL and your credentials belong to the integration, not to the facility. One of The error code and message on a failed callback delivery. Echo of the requestId from the original Gateway-to-HIP request requestId received in the original Gateway request to HIP bridge Your bridge accepted the callback. The gateway validates the body you send back, so a 200 carrying the wrong body is still a failure.response.requestId echoes the REQUEST-ID you sent to m2_link_care_context_notify.Authorizations
Authorizationbearer tokenRequiredaccessToken from POST /api/hiecm/gateway/v3/sessions. Send it as Authorization: Bearer <ACCESS_TOKEN>. M2 also uses per flow tokens, a link token for linking and an authorisation token for patient scoped calls. Their header names are not yet published.Headers
REQUEST-IDstringRequiredTIMESTAMPstringRequiredZ suffix, from a synchronised clock. The sandbox rejects IST and accepts UTC.X-HIP-IDstringRequiredBody
acknowledgementobjectRequiredacknowledgement.statusstringRequiredSUCCESSERROREDerrorobjecterror.codestringRequirederror.messagestringRequiredresponseobjectRequiredresponse.requestIdstringRequiredResponses
200
Where this fits
You produce this callback by calling Link Care Context Notify.