The delivery log
Every attempt, with its status, timing and your own response — and a Redeliver button.
Navigate to: Settings → API keys & webhooks → Webhooks → Deliveries on an endpoint row
What a row records
| Column | What it is |
|---|---|
| When | The moment of the attempt |
| Event | The event type. The event id is stable across every attempt of the same event |
| Attempt | 1 through 8. A retried event has one row per try |
| Status | Delivered with the HTTP code, or Failed with the reason — an HTTP status, or a timeout |
| Time | How long your endpoint took. Anything past 10 seconds is a timeout |
The first 512 characters of your response body are recorded with each attempt too — which is usually where the answer is when a delivery keeps failing.
Redeliver
Redeliver replays that event to that endpoint. The delivery carries Trabalance-Redelivery: true so your side can tell a replay from a first attempt, and the retry cycle starts again from the top. It works after the eighth failure, which is what makes an outage on your side recoverable rather than a hole in your data.
For an OAuth application, the same log is on the app's Webhooks tab in the developer portal, covering deliveries to your one webhook URL across every business that authorised you.
Reading it when something is wrong
- Failed · HTTP 401 / 403 — your endpoint is rejecting us. Check the signature verification, not the payload.
- Failed · Timed out after 10s — you are doing the work before answering. Answer
2xxfirst, queue the work after. - Delivered, but nothing happened on your side — you answered
2xxand dropped it. Nothing on our side will tell you; the log says delivered because it was. - The same event delivered twice — expected, and the reason
Trabalance-Event-Idexists. Deduplicate on it.