About webhooks
Webhooks enable Ondato to send you real-time notifications about changes in the status if your recourses. These are POST requests to your server that are sent as soon as event occurs. The body of the request contains resource information.
Security
Ondato uses HTTPS to send these notifications as a JSON payload.
Ordering
Ondato deliver events asynchronically. Therefore, you might receive them out of order and handle them accordingly.
Webhook IP Adresses
All webhook requests will come from the following IPs:
20.31.227.231
20.76.229.117
20.76.229.248
213.226.187.101
Please make sure that these IPs are whitelisted in order to receive webhook notifications.
Retry Logic
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:
10 seconds
30 seconds
1 minute
5 minutes
10 minutes
30 minutes
1 hour
3 hours
6 hours
Every 12 hours up to 24 hours
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.
How to start receiving webhooks
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 a table below.
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.
Requirements for webhook endpoint
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 contract:
Atrribute | 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 webhpook type attribute, the payload always returns the same information you could obtain from the GET endpoint of the recourse. E.g. of the webhook type is |
| Type of the webook. It contains of two parts:
|
Events
You can configure the following events to trigger a message to registered webhooks:
Wehook event | Webhook is triggered when: | Webhook example |
---|---|---|
Identity Verification (IDV) resource webhooks | ||
| User accepts consent agreement on new identification. | |
| IDV status changes. | |
KYC Identifiation recourse webhooks | ||
| KYC Identification step is started by the customer. | |
| KYC Identification is completed by the customer. | |
| KYC Identification identification is manually or automatically approved. | |
| document data of KYC Identification is updated in Ondato Portal. | |
| KYC Identification is manually or automatically rejected. | |
KYB Identification resource webhooks | ||
| Customer finished filling in business onboarding form. | |
| All KYC identifications were approved and all registries checks were successfully validated. | |
| Not all KYC identifications were approved and/or not all registries were successfully validated. | |
| KYB related document entity is created in the KYB identification with status “NeedReview”. | |
| KYB related document file is uploaded to the document entity. | |
| KYB related document is verified and status is changed from “NeedReview” to “Validated”/ “Invalidated”. | |
| KYB related document is deleted from KYB identification. |
0 Comments