Delivery and retries

Handle webhook attempts, timeouts, backoff, logs, and endpoint failures.

Any non-2xx response, network exception, or ten-second abort fails an attempt. Jetrepo makes five total attempts with exponential backoff using a five-second base delay.

Receiver pattern

1. Verify the signature and timestamp.
2. Use webhook-id as the idempotency key.
3. Persist the event to a durable queue.
4. Return 2xx before the ten-second timeout.
5. Process downstream work idempotently.

Retries keep the same message ID and JSON payload. Each attempt gets a new signing timestamp and signature.

verify → deduplicate → durable enqueue → 202

A delivery log records the URL, event type, message ID, status, response status, attempt count, and safe error text. Logs appear newest first; the current public query returns the 50 most recent records.

Access

Inspecting subscriptions and delivery logs requires webhook.read with matching Backend scope.

Terminal failures

There is no manual resend or replay and no automatic subscription disable. After fixing the endpoint, reconcile from current delivery state or your own event ledger instead of assuming Jetrepo will repeat the event.

Queue dispatch is best effort. Dispatch failure does not fail the source content mutation.

Related

• Verify signatures
• Webhook events
• Configure webhooks