DatoCMS needs to get a status code 2XX
reply from the configured URL to confirm that the notification sent via HTTP POST has been successfully delivered. If any webhook returns a different status code or times out, DatoCMS will set the status as "Failed".
Webhook triggers let you specify under which circumstances an HTTP call will be performed towards your endpoint:
You can add as many triggers as you want to a single webhook. DatoCMS supports events for the following objects:
Entity | Available events | Additional notes |
---|---|---|
Record | "create", "update", "delete", "publish", "unpublish" | You can trigger the webhook only for specific records or records belonging to specific models. |
Model | "create", "update", "delete" | You can trigger the webhook only for specific models. Changes made to a model's field will trigger a call as well. |
Upload | "create", "update", "delete" | |
Build trigger | "deploy_started", "deploy_succeeded", "deploy_failed" | |
Environment | "create", "update", "promote", "delete" | |
Maintenance Mode | "change" | Triggers whenever an admin activates or deactivates the maintenance mode. |
SSO User | "create" | Triggers when an SSO User is added to a project as a collaborator. |
CDA Cache Tags | "invalidate" | Triggers when CDA Cache Tags need to be invalidated. |
Visit the Data consistency: key concepts and implications section for more details on when the webhooks related to the records will be triggered.
DatoCMS will perform an HTTP POST request towards the specified endpoint. The HTTP body will be in JSON format, and will contain all the information relevant to the event just happened.
The body will contain the following information:
Payload property | Description |
---|---|
site_id | ID of the project where the event occurred. |
webhook_id | ID of the webhook that triggered the delivery. |
environment | ID of the environment where the entity resides. |
is_environment_primary | Whether the environment where the event occurred is the primary environment. |
webhook_call_id | ID of the specific webhook event that triggered. |
event_triggered_at | Date when the event originally occurred. |
attempted_auto_retries_count | If auto-retry is on for the webhook, this field displays the number of the current attempt. |
entity_type | The type of entity that triggered the webhook (ie. item, item_type...) |
event_type | The type of event that triggered the webhook (i.e.: create, update, delete...) |
entity | The full payload of the entity serialized according to our Content Management API schema. |
previous_entity | Only present if the event type is "Record > Update". It represents the serialized record BEFORE the update (useful to know what changed). |
related_entities | An array containing all serialized entities specified in the entity's relationships. |
As an example, in the case of a Record > Update event, you can access the record state both before the update operation (previous_entity
) and after (entity
), making it easier to make a diff and see exactly what fields in the record changed:
{"site_id": "example-site-id","webhook_id": "123","environment": "foo-bar","is_environment_primary": true,"webhook_call_id": "456","event_triggered_at": "2024-08-26T14:30:00Z","attempted_auto_retries_count": 3,"entity_type": "item","event_type": "update","entity": {"id": "39830648","type": "item","attributes": {"name": "Mark Smith"},"relationships": {"item_type": {"data": {"id": "810928","type": "item_type"}},"creator": {"data": {"id": "42011","type": "account"}}},"meta": {"created_at": "2018-10-28T18:44:32.776+01:00","updated_at": "2021-08-17T09:11:56.145+02:00","published_at": "2021-08-17T09:11:56.143+02:00","first_published_at": "2018-10-28T18:44:32.789+01:00","status": "published","current_version": "117626080"}},"previous_entity": {"id": "39830648","type": "item","attributes": {"name": "John Smith"},"relationships": {"item_type": {"data": {"id": "810928","type": "item_type"}},"creator": {"data": {"id": "42011","type": "account"}}},"meta": {"created_at": "2018-10-28T18:44:32.776+01:00","updated_at": "2021-08-17T09:11:53.371+02:00","published_at": "2021-08-17T09:11:53.367+02:00","first_published_at": "2018-10-28T18:44:32.789+01:00","status": "published","current_version": "117626079"}},"related_entities": [{"id":"810928","type": "item_type","attributes": {"name": "Author","api_key": "author",...},"relationships": { ... }}]}
If you want, you can also customize the HTTP body of the outgoing requests. To do that, hit the Send a custom payload? switch and provide the new payload.
You can use the Mustache language to make the payload dynamic. The original payload we would send is used as source for the template. You can experiment with the Mustache language in their sandbox, or read their docs.
As an example, this custom payload template:
{"message": "{{event_type}} event triggered on {{entity_type}}!","entity_id": "{{#entity}}{{id}}{{/entity}}"}
Will be converted into the following HTTP body:
{"message": "update event triggered on item!","entity_id": "123213"}
You are not limited to send JSON payloads: just make sure that if the payload is not in JSON format, you configure the proper Content-Type
header.
Similarly, you can also insert Mustache tags in the webhook URL.
Optionally, you can activate the Automatic Retry option in your webhook settings, so that in case of delivery failure, DatoCMS will attempt to resend the request up to 7 times, with increasing intervals between each attempt.
Each retry will use the most recent webhook settings, and the retry schedule is as follows:
Retry | Time |
---|---|
1 | 2 minutes after the failure |
2 | 6 minutes after the previous retry |
3 | 30 minutes after the previous retry |
4 | 1 hour after the previous retry |
5 | 5 hours after the previous retry |
6 | 1 day after the previous retry |
7 | 2 days after the previous retry |
Webhook calls can have different statuses to indicate the outcome of the delivery attempt:
Status | Description |
---|---|
Pending | The webhook call is currently being executed. |
Success | The webhook call was successfully delivered to the specified endpoint, and the server responded with an HTTP status code in the 2xx range. |
Failed | The webhook call could not be successfully delivered. This may be due to issues such as server errors, invalid endpoints, network problems or an HTTP status code not in the 2xx range. |
Rescheduled | The webhook delivery failed, but is scheduled to be retried automatically based on the webhook automatic retries setting. |
You can browse webhook activity under the Project Settings > Webhooks activity log section of your project, or using our API. In both cases, you can filter/order webhook calls to refine your search based on various criteria, such as status, type of event, date, etc:
At any time you have the option to resend a webhook manually. To do so, click on the "Details" link and then on "Resend now"
When you choose to manually resend a webhook call, the system will repeat the exact same call with the updated webhook settings. If auto-retries are enabled:
a successful manual resend will stop further auto-retry attempts,
a failed manual resend won't add to the count of automatic retries.
DatoCMS enforces two timeout limits for webhook integrations:
Connection Timeout: 2 seconds
This is the maximum time allowed to establish the initial connection to the webhook's HTTP server.
Total Execution Timeout: 8 seconds
This is the maximum time allowed for the entire webhook process to complete.
If your service exceeds either of these timeouts, DatoCMS will terminate the connection. The delivery attempt will then be marked as either Failed — or Rescheduled, if Automatic Retries are enabled.
Due to the unpredictable nature of service completion times, it's recommended to handle the bulk of your processing in background jobs. This approach helps manage DatoCMS's timeout constraints effectively. Consider using job queue libraries such as Resque (Ruby), RQ (Python), or RabbitMQ (Java).
The pattern we suggest is to perform the initial validation checks of the payload quickly and synchronously before starting the background jobs. This allows you to potentially respond with a status code other than 2XX
to the webhook, thereby notifying DatoCMS of the issue.