What happens when webhook deliveries fail?

Requires Elite

Short answer

Every delivery has 10 seconds; after that — or on network errors and non-2xx responses — it’s recorded as failed in the delivery log (status code or error text). There is currently no automatic retry: every event is delivered exactly once (at-most-once). You catch up on missed events via the log plus an API reconciliation; you repeat tests with “Send test”.

Prerequisites

Open the delivery log. Administration → Webhooks → select a webhook. The log shows the most recent deliveries with event, success, status code, and, if applicable, an error message (e.g., HTTP 500 or a connection error).
Interpret the errors. HTTP 4xx/5xx = your endpoint responded, but not with 2xx (signature check? a bug? maintenance?). An error message with no status code = your endpoint wasn’t reachable at all (DNS, TLS, timeout after 10 s).
Test again. After fixing the issue, trigger a signed ping event with “Send test” and check the new log entry.

The delivery log returns the last 50 entries, newest first:

curl -H "Authorization: Bearer inv_dein_token" \
  https://demo.notory.io/api/v1/webhooks/018f9f44-5e6f-7a77-b182-9c0d1e2f3a41/deliveries

[
  {
    "id": "018f9f50-aaaa-7bbb-cccc-1d2e3f405162",
    "webhook_id": "018f9f44-5e6f-7a77-b182-9c0d1e2f3a41",
    "event": "asset.created",
    "success": false,
    "status_code": 500,
    "error": "HTTP 500",
    "created_at": "2026-07-08T11:20:44Z"
  },
  {
    "id": "018f9f4e-bbbb-7ccc-dddd-2e3f40516273",
    "webhook_id": "018f9f44-5e6f-7a77-b182-9c0d1e2f3a41",
    "event": "ping",
    "success": true,
    "status_code": 204,
    "error": null,
    "created_at": "2026-07-08T11:05:02Z"
  }
]

A failed delivery cannot be re-triggered via the API; only the test delivery is repeatable (POST /api/v1/webhooks/{id}/test). To catch up on missed asset.created events, reconciling against the asset list works well:

curl -H "Authorization: Bearer inv_dein_token" \
  "https://demo.notory.io/api/v1/assets?page=1&page_size=100"
# → reconcile against your own data (created_at since the last success)

What happens behind the scenes?

Anatomy of a delivery. An event occurs → Notory determines the tenant’s active, subscribed webhooks → POST with signature, 10 s timeout → the result (success, status_code, error) is stored as a log entry. Only a 2xx response counts as a success.
At-most-once, no backoff. There is no automatic retry, no backoff queue, and no deactivation after a streak of failures — every delivery is a single attempt. Design your receiver accordingly: small, fast, highly available; do heavy work asynchronously behind it.
The trigger never suffers. Deliveries run after the actual action as a background task (best-effort). A dead receiver therefore never slows down or prevents the creation of an asset.
Recommended receiver strategy. Respond immediately with 204 (accept first, process later), process idempotently (e.g., keyed on data.id), and after an outage, reconcile the affected time range via the API instead of waiting for a repeat delivery.
Retention. The log shows the last 50 deliveries per webhook — for longer-term analysis, keep your own logs on the receiver side.