Introduction to webhooks
Our platform delivers updates to your webhook in real-time. Below is a detailed overview of how updates work and how you can handle them correctly.
Webhook Endpoint
- All updates are sent to a single webhook URL, which you configure in the dashboard.
- Only one webhook URL can be set per account.
Request Format
- The request is sent as a
POST
request. - The
Content-Type
isapplication/json
. - The request contains a
Bearer
token in theAuthorization
header (configured in your webhook settings).
Example Request
POST /your-webhook-endpoint HTTP/1.1
Authorization: Bearer YOUR_WEBHOOK_TOKEN
Content-Type: application/json
{
"updates": [
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"event": "event_name",
"payload": {
"some_id": 12345,
"some_field": "some_data"
}
}
]
}
Preventing Duplicate Processing
To avoid duplicate updates:
- Store received
id
values and check against them before processing. - If an update with a previously processed
id
is received, ignore it.
Batch Processing
- We group updates into batches and send up to 10 updates in a single request.
Response Handling
- A request is considered successful if the response status code is any 2xx (e.g.,
200 OK
). - If the request fails or times out, retries are scheduled with an exponential delay.
Retry Logic
If the webhook does not respond successfully within 10 seconds, we will retry up to 9 times with the following delay schedule:
Attempt | Delay |
---|---|
1st | 5 minutes |
2nd | 5 minutes |
3rd | 15 minutes |
4th | 30 minutes |
5th | 1 hour |
6th | 6 hours |
7th | 12 hours |
8th | 1 day |
9th+ | 1 day |
- Once a successful response is received, the normal delivery schedule resumes.
- If no successful response is received after 10 attempts, the webhook will be deactivated.
Reactivation
To reactivate the webhook, update it in the dashboard.