Webhook clients
Business functionality and API endpoints available to a "Webhook" client.
OpenCRVS publishes the following civil registration events as webhooks that clients can subscribe to. This is particularly useful for e-Gov systems if you wish to initiate business functionality for a citizen at the moment a Birth or Death is officially registered.
Birth registration
Death registration
Included in these webhooks is a FHIR Resource type and unique ID to the OpenCRVS resource associated and customisable demographics, attachments and links to biometric data for the registration in a SHA signed and encrypted payload.
Subscribing to an OpenCRVS webhook requires you to develop a service that exposes the standardised and required webhook endpoints associated with the W3C WebSub pattern.
Any service that subscribes to an OpenCRVS webhook must:
Expose endpoints on a secure server that can process HTTPS requests and respond to a webhook following the WebSub pattern.
Authenticate and query OpenCRVS to find a list of available event webhooks.
Authenticate and subscribe to the webhook of choice.
Respond to the webhook event as you wish internally, and request further details from OpenCRVS via a Record Search if you need to.
You can use our Postman collections to test webhook API functionality. Postman is a tool you can download to test API access before building your integrations.
As an example 3rd party webhook client service, we have written this mediator that subscribes to a birth registration webhook and retrieves the data required by MOSIP - the Modular Open Source Identity Platform to register a national ID in MOSIP at the moment a Birth is registered. This medator only works for a National ID client explained later, but you can refer to the code to replicate the sequence diagrams below regarding subscribing and handling webhooks.
Creating a subscriber endpoint
Your mediator must be able to process two types of HTTPS requests:
Verification Requests
Webhook Events.
Since both requests use HTTPs your server must have a valid TLS or SSL certificate correctly configured and installed.
The following sections explain what will be in each type of request to these endpoints and how to respond to them.
Verification Requests
Anytime you try to subscribe to a webhook, OpenCRVS will send a GET request to this endpoint URL to confirm that your mediator is prepared to receive webhook events.
Sample:
Parameter | Sample value | Description |
---|---|---|
|
| This value will always be set to |
|
| A random cryptographic string that you must pass back to OpenCRVS |
|
| A supported OpenCRVS event type string that will trigger this webhook |
Note: The supported events and associated topic strings are explained later in this document when studying the subscription process.
Validating Verification Requests
Whenever your endpoint receives a verification request, it must:
Verify that the topic
value matches the event you're trying to subscribe to. Respond with the following object:
Webhook Events
Whenever there's a a new event created, we will send your endpoint a POST request with a JSON payload. When you create or edit a webhook client, you select the data you wish to be contained in the payload using the checkboxes.
For example, if you subscribed to the birth registration event, we would send you a POST request to the same URL as the Verification request URL that would look something like this depending on what content you configured in the screen above:
The property context
contains the FHIR bundles. Refer to our standards section to learn more about the FHIR specification.
Parameter | Sample value | Description |
---|---|---|
|
| The unique |
|
| A timestamp identifying the time that the webhook was created |
|
| A supported OpenCRVS event type string that triggered this webhook. |
|
| The FHIR resources bundle associated with the target of this webhook. |
|
| The URL that is notified by this webhook |
|
| The request signature that is created using your |
Validating Payloads
We encrypt the payload using your client's sha_secret
in an SHA256 signature hash and include the hash in the request's hmac
property, preceded with sha256=
.
This method shows how we create the signature to help you understand how you might create a similar hash and compare them.
You must confirm that the data is genuinely received from OpenCRVS and not from a malicious man-in-the-middle by using the sha_secret in this way
To validate the payload in a similar way to our method:
Generate a SHA256 signature using the context
array contents at position [0] as the rawBody
. signingSecret
is your OpenCRVS sha_secret
, available to you as an environment variable and generated via the register step. requestSigningVersion
is "sha256"
Compare your signature to the hmac
prop. If the signatures match, the payload is genuine.
Please note that we generate the signature using an escaped unicode version of the payload, with lowercase hex digits. If you just calculate against the decoded bytes, you will end up with a different signature. For example, the string äöå
should be escaped to \u00e4\u00f6\u00e5
.
Responding to Webhook Events
Your endpoint should respond to all events with 200 OK HTTPS
.
Frequency: Be sure to adjust your servers to handle each Webhook individually and at any time.
Unacknowledged responses are retried according to the capabilities of our library used bullmq.
Subscription process
Firstly, ensure that you have correctly configured your subscriber endpoint above to respond to Verification Requests and Webhook Events.
To subscribe, your subscription service must request an authorization token using your client_id
and client_secret
.
With the token you can now perform the following actions:
List webhook subscribers
This API returns all clients that are subscribed to receive webhook notifications.
URL
Request headers
Response payload
Example json
Subscribe to a webhook
This API subscribes a client service to an OpenCRVS webhook using a supported OpenCRVS event type string as a trigger.
URL
Request headers
Request payload
Parameters contained within the hub
object:
Parameter | Sample value | Description |
---|---|---|
|
| The URL address that will be requested when the event occurs. |
|
| Always set to |
|
| A supported OpenCRVS event type string that will trigger this webhook. |
|
| Your OpenCRVS |
The supported events and associated topic string:
Webhook event | trigger |
---|---|
|
|
|
|
Response payload
The subscribe process will test the authenticity of the sha_secret
and additionally make a test GET request to the Verification Request
Provided all is successfully completeed, your webhook will be subscribed and you will receive a 202 status code and empty response.
Unsubscribe to a webhook
This API unsubscribes a client service to an OpenCRVS webhook using the webhook id.
You may notice that as of OpenCRVS v1.2.*, webhook clients have the ability to unsubscribe themselves or other webhook clients to webhook events. In this version of OpenCRVS it is assumed that all webhooks created by the system administrator can be trusted not to interfere with each other's subscriptions.
URL
Request headers
Response
204 status code and an empty response will be returned when the webhook has been successfully deleted.
Last updated