Webhooks allow you to integrate Administrate with external systems by sending data when specific events occur.
The Webhook Logs section of the Control Panel allows you to:
- check the status of configured Webhooks
- review events processed by a Webhook
- inspect responses and payloads for troubleshooting
- re-run events when needed
On this page
- Webhook statuses
- View webhook events
- Webhook log fields
- Run an event again
- Advanced Webhooks
- Troubleshooting via Webhook Logs
- Related documentation
Webhook statuses
The first screen in the Webhook control panel lists each configured Webhook, its current status, and the event that triggers it.
| Status | Description | Triggers Webhook? | Log Entry Created? | Result in Log |
|---|---|---|---|---|
| Active | The Webhook is enabled and will trigger as expected. | Yes | Yes | Result of the Webhook |
| Disabled | The Webhook is turned off and will not trigger, but activity is still recorded. | No | Yes | Not Sent |
| Inactive | The Webhook is deactivated and does not trigger or log any activity. | No | No | N/A |
View webhook events
Click the action button in the Webhook table to view the events that have been sent to that Webhook.
Webhook log fields
Each log entry includes details about the event sent to the Webhook and the response returned.
| Field | Description |
|---|---|
| Result | Whether the Webhook successfully processed the event. |
| Triggered At | The time the event was triggered and sent to the Webhook for processing. |
| Payload | The information sent to the Webhook. |
| Response Code | The HTTP status code 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 the three-dot menu and select Raw Response. |
The information shown in Response varies depending on the Webhook implementation and is often used for debugging.
Run an event again
From the log view, you can choose to run an event again. This is useful when the original attempt failed due to a temporary issue, such as a networking problem.
Selecting Run Again creates a new event entry and submits it for processing. The new run appears as a separate log entry, while the original entry remains for reference.
Advanced Webhooks
Webhooks can be configured to fire only when certain conditions are met. This helps prevent unnecessary integrations and reduces system load.
These conditions are defined using a filter expression, which is evaluated against the webhook payload before the Webhook is sent.
The GraphQL mutations used to create or update a Webhook support the optional filterExpression parameter.
For more details, see: WebhookUpdateInput documentation
Troubleshooting via Webhook Logs
Each webhook log stores the filter expression used at the time the event was processed. This allows you to debug behavior even if the Webhook configuration has changed.
A result of Not Sent means the Webhook did not fire due to filter rules, not because of an error.
You can open a log entry to review:
- the payload
- the filter expression used
- whether the event matched the filter
Related documentation
For more information on creating and configuring Webhooks, see: Webhooks developer guide
For more information on filtering, see: JMESPath documentation