Table of Contents
Webhooks allow Ondato to send you real-time notifications regarding changes in the status of your resources. These notifications are sent as POST requests to your server immediately after the event occurs. The request body includes information about the resource.
Ondato uses HTTPS to send these notifications as a JSON payload.
Ondato delivers events asynchronously. Therefore, you might receive them out of order and need to handle them accordingly.
All webhook requests will originate from the following IP addresses:
20.31.10.47 20.31.227.231 20.76.229.117 20.76.229.248 213.226.187.101 |
Please make sure to whitelist the following IPs in order to receive webhook notifications.
Please make sure to whitelist the following IPs in order to receive webhook notifications.
Upon sending a webhook notification, we are waiting for a success response for 30 seconds. Otherwise, if your endpoint does not respond, the webhook is queued for retry. We use an exponential backoff retry policy for event delivery. The attempt to resend the notifications is according to the following schedule on a best effort basis:
|
If the endpoint responds within 3 minutes, we will attempt to remove the event from the retry queue on a best effort basis but duplicates may still be received.
A small randomisation is added to all retry steps and may opportunistically skip certain retries if an endpoint is down for a long period o appears to be overloaded.
Maximum number of retry attempts is 30.
When Event Grid can't deliver an event within a certain time period or after trying to deliver the event a certain number of times the event is dropped.
To start receiving event notifications into your application you need to go through the following steps:
Identify the events you want to monitor.
Please see a full list of events in this section here: https://ondato.atlassian.net/wiki/spaces/PUB/pages/2296184995/Webhooks#%F0%9F%AA%84-Types.
Create a webhook endpoint as an HTTP
endpoint on your local server.
Handle requests from Ondato.
Deploy your webhook endpoint so it would be publicly accessible HTTPS
URL.
Contact Ondato support team to register the publicly accessible HTTPS
URL and a list of events you want to monitor.
Please note that we also support multiple URLs for sending webhooks.
Please note that we also support multiple URLs for sending webhooks.
Ondato needs to know where to send information about events. In order to receive webhooks you need to create a webhook endpoint and provide us with the publicly accessible HTTPS
URL that would meet the following criteria:
URL format: https://<your-website-name>/<your-webhook-endpoint>.
URL must support POST HTTP Method.
URL must support one of the available authentication flows:
basic
- username, password.
oAuth2
- clientID, clientSecret, tokenUrl.
Events sent by Ondato will have a body in the following structure:
Property | Description | |
---|---|---|
| Webhook ID | |
| Internal ID that identifies you in Ondato system. | |
| Date and time when webhook was generated. | |
| Date and time when webhook was delivered.
| |
| Status of the webhook if it was delivered or not. Possible values are true/ false.
| |
| Depending on the webhook type property, the payload always returns the same information you could obtain from the E.g. of the webhook type is | |
| Type of the webhook. It contains of two parts (the first part identifies the service and the second one the event): |
You have the option to configure various webhook types that can trigger a message to registered webhooks. |
IdentityVerification.StatusChanged
|
|
|
IdentityVerification.Consented
|
For this webhook type, the payload body depends on the IDV API →
/v1/identity-verifications/{id}
contract.
In the webhook payload, you receive the "id" as a reference to the Consents API.
You can call Consents API by using “id” →
/v1/consents/{id}
to retrieve the information about the consent session.
For this webhook type, the payload body depends on the IDV API → GET /v1/identity-verifications/{id}
contract.
In the webhook payload, you receive the "id" as a reference to the Consents API.
You can call Consents API by using “id” → GET /v1/consents/{id}
to retrieve the information about the consent session.
|
|
Following fields can be ignored (are depreciated):
|
KycIdentification.Created
|
For this webhook type, the payload body depends on the KYC ID API → /v1/identifications/{id}
contract.
You can call KYC ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYC ID API → GET/v1/identifications/{id}
contract.
You can call KYC ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KycIdentification.Processed
|
For this webhook type, the payload body depends on the KYC ID API → /v1/identifications/{id}
contract.
You can call KYC ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYC ID API → GET/v1/identifications/{id}
contract.
You can call KYC ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KycIdentification.Approved
|
For this webhook type, the payload body depends on the KYC ID API → /v1/identifications/{id}
contract.
You can call KYC ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYC ID API → GET/v1/identifications/{id}
contract.
You can call KYC ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KycIdentification.Updated
|
For this webhook type, the payload body depends on the KYC ID API → /v1/identifications/{id}
contract.
You can call KYC ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYC ID API → GET/v1/identifications/{id}
contract.
You can call KYC ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KycIdentification.Rejected
|
For this webhook type, the payload body depends on the KYC ID API → /v1/identifications/{id}
contract.
You can call KYC ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYC ID API → GET/v1/identifications/{id}
contract.
You can call KYC ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Created
|
For this webhook type, the payload body depends on the KYB ID API → /v1/identifications/{id}
contract.
You can call KYB ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/identifications/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Approved
|
For this webhook type, the payload body depends on the KYB ID API → /v1/identifications/{id}
contract.
You can call KYB ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/identifications/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Rejected
|
For this webhook type, the payload body depends on the KYB ID API → /v1/identifications/{id}
contract.
You can call KYB ID API by using “id” →
/v1/identifications/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/identifications/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/identifications/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Document.Created
|
For this webhook type, the payload body depends on the KYB ID API → /v1/documents/{id}
contract.
You can call KYB ID API by using “id” →
/v1/documents/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/documents/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/documents/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Document.Uploaded
|
For this webhook type, the payload body depends on the KYB ID API → /v1/documents/{id}
contract.
You can call KYB ID API by using “id” →
/v1/documents/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/documents/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/documents/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Document.Updated
|
For this webhook type, the payload body depends on the KYB ID API → /v1/documents/{id}
contract.
You can call KYB ID API by using “id” →
/v1/documents/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/documents/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/documents/{id}
to retrieve the information about the user session.
|
|
KybIdentification.Document.Deleted
|
For this webhook type, the payload body depends on the KYB ID API → /v1/documents/{id}
contract.
You can call KYB ID API by using “id” →
/v1/documents/{id}
to retrieve the information about the user session.
For this webhook type, the payload body depends on the KYB ID API → GET/v1/documents/{id}
contract.
You can call KYB ID API by using “id” → GET /v1/documents/{id}
to retrieve the information about the user session.
|
|