Skip to main content

Testing and debugging

Webhook activity log
Link 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".

Click view details to view the webhook request and response

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.

The request and response are shown on one screen

Refreshing the activity log
Link 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 refresh icon allows you to refresh the recent deliveries list

The recent deliveries list is updated and we can see that the webhook request has now been sent.

The recent deliveries list is updated and shows the new webhook delivery

Resending a request
Link 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.

You can resend a webhook request from the webhook details window

Testing a webhook
Link 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).

You need to select a previous delivery to use to test your webhook settings

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.

The webhook is invoked in testing mode and no request is sent to the webhook URL

Errors and retries
Link 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".

Dynamic Content will retry the webhook if an error occurs

Our webhook retry policy is based on REST Hooks and is also summarised below.

ResponseRetry?
2xxNo
3xxNo
4xx (excluding 410)Yes
410No
5xxYes
Timed outYes

Custom payload retries
Link 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.

Statuses
Link 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.

StatusDescription
Building custom payloadShown 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 payloadThere 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 deliveryThe request is queued awaiting delivery. This is the initial webhook state
Scheduled for retryThe system is waiting for until the specified time interval to attempt redelivery
Failed AttemptThe 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.

Customizable webhooks

Webhook payloads

withDeliveryContentItem helper