Skip to content
Jetrepo
Esc
↑↓navigate↵open⌘Jpreview
On this page

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 record retains the URL, event type, message ID, status, response status, attempt count, and safe error text. The governance console has no webhook-log screen, and the four Management tools currently expose no dedicated delivery-log inspection kind. Operators can investigate receiver and service logs.

Access

Webhook read authority is webhook.read with matching Backend and Environment scopes; it does not imply that a removed management query or console screen exists.

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.

Was this page helpful?