Testing and debugging
Webhook activity logLink copied!
When a webhook is triggered, the information about each delivery or attempted delivery is listed in the "Recent deliveries" section of the webhook activity log. Each time the webhook is triggered an entry will be added to the list.
To view the webhook history click the "Activity log" tab at the top of the window.
The list will show a delivery ID, a unique value generated each time a request is sent, the time it was created (triggered), the time it was invoked (delivered or attempted) and the current status of the delivery.
To view the request sent by Dynamic Content to the webhook URL, together with the response, click "View details".
An example of the request sent to a webhook that accepts the content created webhook event is shown below. The request consists of headers and a body. The request URL and the invocation timestamp (ISO-8601 format including UTC offset) are also displayed. In this example the webhook URL was triggered by the user creating a content item, so the payload includes information about the updated item such as the current version and the creation and modification date.
In this example we can see that the webhook request was handled successfully with a response code of 200 and no response body was returned.
In many cases another app will be requested to perform a certain action when the webhook is triggered. If this app returns an error, you can include the error in the response body so that it will be logged in the webhook history. If the webhook was not sent, for example because a filter did not match or because processing failed, no response will be shown. However the (unsent) request will still be displayed to assist with debugging.
Refreshing the activity logLink copied!
When a webhook is triggered, the request is put in a queue, so it may not be sent immediately. The refresh icon (1 in the image below) allows you to refresh the recent deliveries list so you can check for new entries.
In the example below, the webhook has been triggered by updating a content item. The activity log is then opened and it shows that the webhook request has not yet been sent. So we'll click the refresh icon to update the recent deliveries list.
The recent deliveries list is updated and we can see that the webhook request has now been sent.
Resending a requestLink copied!
When you're developing a webhook integration, it may take a while to get the service that responds to the request configured correctly. The resend feature allows you to resend a webhook without having to trigger it again, allowing you to focus on getting your integration configured to process and respond to the webhook request.
To resend a request, open the activity log, choose a recent delivery and click "View details". Click the "Resend" button at the top of the webhook details window (1 in the image below). The webhook will then be resent and you can view the request and response for the new webhook delivery.
Note that you can only resend a successful request or a request that has a status of "Failed attempt" or "Failed to build custom payload". See errors and retries for more details about status codes and retries.
Testing a webhookLink copied!
The webhook testing feature allows you to test out your webhook settings, such as your filters and custom payload, without having to trigger the webhook each time you make a change. This is particularly useful when you're refining your custom payload.
To use the testing feature you need to have triggered the webhook at least once to provide you with a webhook delivery to test with the new settings. Open the testing pane (1 in the image below), choose a recent webhook delivery and click the "Test" button (2).
The webhook will be invoked in testing mode and the webhook request will be displayed, but no request will be sent to the webhook URL. The latest version of your settings will be used for testing, so you don't need to save the changes before you test.
In the example shown below we have triggered a webhook without a custom payload to use for testing. We then added the custom payload and tested the webhook. The output of the custom payload is shown in the webhook body.
Errors and retriesLink copied!
When an error occurs, such as a 404 if the webhook URL can not be found, then multiple delivery attempts are shown in the webhook history under the same delivery ID.
In the example below, the webhook URL cannot be found. Dynamic Content will retry up to 11 times within a total of 13 hours. If the webhook URL does not respond after this time, then the request status will be changed to "Failed attempt".
We may disable retries on webhooks that continue to error for more than 24 hours. Retries will be re-enabled once a successful delivery is received. See the retry policy below.
Our webhook retry policy is based on REST Hooks and is also summarised below.
| Response | Retry? |
|---|---|
| 2xx | No |
| 3xx | No |
| 4xx (excluding 410) | Yes |
| 410 | No |
| 5xx | Yes |
| Timed out | Yes |
Custom payload retriesLink copied!
If you use our withDeliveryContentItem helper, HTTP requests to the virtual staging environment APIs will be made from within custom payloads.
These requests will be retried in the following circumstances:
- Time out: the request takes longer than 5 seconds.
- Rate limiting: 429 returned. Too many requests on the virtual staging environment.
- Server error: 500, 501, 502, 503 or 504 returned.
Dynamic Content will retry building the custom payload for up to 1 hour with a maximum of 10 attempts. During this period, the webhook will error in the "Custom payload retry pending - attempt #n" state. After an hour the webhook will error in the "custom payload failed to build" state. The webhook can then be manually resent.
Note: if the webhook payload takes too long to generate for another reason (for example: very complex handlebars), it will not retry but will fail to build.
StatusesLink copied!
The following statuses may also be shown in the activity log. These are in addition to statuses in the 200 or 400 range which indicate success or an error response. Some of these will only be shown when using features such as custom payloads.
| Status | Description |
|---|---|
| Building custom payload | Shown while the custom payload is being generated. |
| Custom payload retry pending - attempt #n. | The custom payload did not build due to a problem retrieving content. The system is waiting for the specified time interval to make another attempt to build the custom payload. See custom payload retries above for more details. |
| Failed to build custom payload | There was an error building the custom payload. Check the webhook details for more information. |
| Not sent (filtered) | The webhook request was filtered out by your filters, for example on content type. |
| Scheduled for delivery | The request is queued awaiting delivery. This is the initial webhook state |
| Scheduled for retry | The system is waiting for until the specified time interval to attempt redelivery |
| Failed Attempt | The number of retries has been exceeded and no further retries will be attempted. The webhook can still be resent |
Note that webhook activity logs are retained for 30 days.