Debugging webhook delivery failures

Click an endpoint at /dashboard/reseller/webhooks to open its delivery log — the last 100 attempts with status, HTTP code, response body excerpt, and retry schedule. The log is the first place to look when an upstream system stops receiving events.

Log columns

• Event — the event type and a short payload preview. Click to expand the full JSON we POSTed.

• Status — PENDING (queued), SUCCESS (2xx returned), FAILED (non-2xx but retryable), EXHAUSTED (8 attempts up, no longer retried).

• HTTP — your endpoint's response code; missing means we couldn't reach it (DNS, TLS, connection refused).

• Attempts — how many tries so far out of 8. The next-attempt timestamp shows when we'll retry.

• Response excerpt — first 500 bytes of your endpoint's response body. Often contains the actual error message from your framework.

Common failure patterns

401 / 403 — signature mismatch

Your verification logic is rejecting the request. The most common cause: hashing a re-stringified copy of the body instead of the raw bytes. Frameworks like Express need app.use(express.raw()) on the webhook route — JSON middleware mutates the payload before you hash it. Fix the verifier, then hit "Replay" on a failed delivery to confirm.

404 — endpoint moved

Edit the endpoint URL in the dashboard. Existing PENDING deliveries pick up the new URL on their next retry.

5xx — your service was down

We back off exponentially: 1 min, 5 min, 30 min, 2 hours, 12 hours, 24 hours, 48 hours, 72 hours. As long as your endpoint recovers within that window the event lands. If it doesn't, the delivery flips to EXHAUSTED and stays in the log for audit but won't fire again.

Connection / TLS errors

Cert expired, DNS pointing at the wrong host, firewall blocking our egress IPs. The "Response excerpt" column will say ECONNREFUSED, certificate has expired, etc. Fix the underlying infra issue, then "Replay" failed deliveries.

Manually replaying a delivery

Each row has a Replay action that re-queues the same payload + delivery id. The Delivery-Id is unique per attempt-set so your side can dedupe — replaying intentionally reuses the original id, which means if you've already processed it, your idempotency layer will short-circuit and that's expected.

Rotating the signing secret

Delete the endpoint and add a fresh one. The new endpoint gets a new secret revealed once at creation time. Outstanding deliveries from the deleted endpoint stay in the log for audit but won't fire — recreate any URL you need on the new endpoint.

What we don't retry

If your endpoint returns 410 (Gone), we mark the delivery EXHAUSTED immediately and stop retrying that event. Use 410 from your side when you've intentionally taken the endpoint down for good.