Webhooks allow you to integrate with systems outside Administrate and send data to those systems using event triggers.
The Webhook Logs section of the Control Panel allows you to check the status of any Webhooks that have been configured and also allows you to review the events that have been processed by a Webhook.
The first screen in the Webhook control panel lists each configured Webhook, and its current status. It also lists the event that triggers the given Webhook.
Clicking on the action button in the table allows you to view the events that have been sent to the Webhook.
| Field | Description |
| Result | Whether the Webhook successfully processed the event. |
| Triggered At | The time that the event was triggered and sent to the Webhook for processing. |
| Payload | The information that was sent to the Webhook |
| Response Code | The HTTP status code that was returned by the Webhook. |
| Object ID | The ID number assigned to the event by Administrate when processing the event. |
| Response | The information returned by the Webhook after processing the event. To see the full response, click on the three dots icon and select "Raw Response" |
The information that is shown in the Response will differ depending on the Webhook implementation. Often this will include technical information that can be used to investigate and debug issues that your Webhook may be encountering. To see the full response, click on the three dots icon and select "Raw Response".
From the Log view, you can choose to run an event again. You may choose to run an event again if the Webhook had encountered a temporary problem, such as a networking error.
Selecting "Run Again" will create a new event and submit it for processing. This will appear as a new entry in the table and the original event will remain in the table for reference.
Advanced Webhooks
Webhooks in Administrate can be further configured to fire requests only if certain conditions are met (i.e., only fire webhook if the update is done in a specific region). The aim is to prevent integrations from running unnecessarily, leading to bandwidth, load, and monetary savings.
These conditions are represented by a filter expression, evaluated on the webhook payload just before the webhook is sent and after the update (or creation, etc.) is done. You can usually view the result of the webhook’s GraphQL query on the updated entity data.
The GraphQL mutations to create/update a webhook supports the optional parameter filterExpression. To update a webhook, and know what is needed in the input and what fields can be updated, refer to the documentation for WebhookUpdateInput.
Troubleshooting via Webhook Logs
When each webhook log is processed, the filter expression that was evaluated is saved with the log itself. Given the webhook expression could change over time, we keep a record of the particular expression that was evaluated at the time of running, for ease of debugging.
Looking at the figure below, we have set a webhook that only triggers for events that happen with the 'Default Region' (See Filter Expression within the Webhook Details).
We also notice in the logs a webhook was not sent. The Not Sent result code indicates that the webhook did not fire due to the filtering rules set and not due to an error.
By clicking on the log item, we can verify that our filtered webhook successfully blocked this event from firing. If you notice that the payload shows the event update occurred in Region: APAC, while the webhook is set to fire for Region: Default Region. The image below shows the payload, the filter expression, and the Matches filter (which shows no) the reason this webhook was not triggered.
For more information on creating and configuring a Webhook, see our developer guide: Webhooks
For more information on Advanced Webhooks and how filtering works, see the documentation for JMESPath.
Comments
0 comments
Article is closed for comments.