Explain payload
When a webhook arrives, Hookdrop reads the full payload and returns a plain English summary of what the event means — what happened, who triggered it, and what the key values are. You don’t need to know the schema ahead of time.
From the dashboard
- Open the Events tab for any endpoint.
- Click the event you want to inspect.
- Click Explain in the event detail panel.
The explanation appears inline below the raw payload.
Via the API
Send a GET request to the explain endpoint, passing your API token in the Authorization header.
curl https://hookdrop.dev/api/endpoints/<endpointId>/events/<eventId>/ai/explain \
-H "Authorization: Bearer YOUR_API_TOKEN"
Response
{
"explanation": "A customer just completed a payment of ₦15,000 for order #1234. The payment was processed successfully via card ending in 4242."
}
The explanation is a single string written in plain English. You can display it directly in your UI, forward it to a Slack channel, or store it alongside the raw event.
Explanations are generated fresh on every request. If the first explanation
is too brief, re-request it — the AI may surface different details on
subsequent calls.
Diagnose failure
When Hookdrop fails to deliver a webhook to one of your destinations, the Diagnose feature analyses the failure and tells you exactly what went wrong and how to fix it.
Common scenarios where diagnosis helps:
- Your server returned a
5xx error
- The connection was refused (e.g. your local tunnel went down)
- The request timed out
From the dashboard
- Open the Events tab for any endpoint.
- Click the failed event (marked with a red status badge).
- Click Diagnose in the event detail panel.
Hookdrop displays the AI diagnosis alongside the delivery attempt logs.
Via the API
curl https://hookdrop.dev/api/endpoints/<endpointId>/events/<eventId>/ai/diagnose \
-H "Authorization: Bearer YOUR_API_TOKEN"
Response
{
"diagnosis": "The delivery failed because your destination returned a 502 Bad Gateway response. This typically means your upstream server (e.g. your app server behind a reverse proxy) was not running or was still starting up. To fix this: (1) confirm your application server is running, (2) check your reverse proxy configuration, and (3) replay the event once your server is healthy."
}
The diagnosis includes:
- What happened — the specific error and HTTP status code
- Why it happened — the most likely root cause
- How to fix it — concrete next steps tailored to the failure type
Diagnose reads the delivery attempt logs for the event. If no delivery attempt
has been made yet (e.g. the event has no configured destinations), the
diagnosis will have limited information to work with.