RevKeen Docs
Webhooks

Retry behavior

Delivery retry schedule, dead-letter policy, and idempotency

RevKeen retries failed webhook deliveries automatically. Your consumer just needs to be idempotent and return 2xx quickly on success.

Retry schedule

A delivery is considered failed if your endpoint returns non-2xx, times out after 30 seconds, or refuses the connection.

AttemptDelay after previous failure
1Immediate (the original delivery)
25 minutes
330 minutes
42 hours
58 hours
624 hours

After 6 attempts RevKeen stops retrying and marks the delivery as dead. Dead deliveries are visible on the endpoint in the dashboard for 30 days before archival.

What counts as a failure

ResponseRetried?
2xxNo — success.
3xxYes — treat as a failure. Do not redirect.
4xxYes — but consider it a bug on your side; alert.
5xxYes.
Timeout (>30s)Yes.
Connection refused / DNS failureYes.
TLS handshake failureYes.

Idempotency contract

Every delivery attempt uses the same event id. Retries do not produce new event IDs.

{ "id": "evt_1a2b3c4d5e6f", "type": "payment.succeeded", "created": 1705689600, ... }

Your consumer should:

  1. Extract event.id on receipt.
  2. Check a persistent store (Redis, DB, idempotency table).
  3. If the ID is new → process and persist the ID.
  4. If the ID is known → return 2xx without reprocessing.

This is the same idempotency pattern used by the REST API — events and API mutations share the guarantee.

Ordering guarantees

Deliveries across different resources are not ordered. subscription.renewed and the matching invoice.paid may arrive in either order, seconds apart.

Deliveries for the same resource are mostly ordered — e.g., subscription.created before subscription.updated — but do not rely on strict ordering for correctness. Always reconcile against the current resource state via a GET before acting on stale assumptions.

Dashboard tools

The endpoint detail page exposes:

  • Deliveries tab — every attempt with request + response bodies, timing, and status.
  • Retry button — manually re-fire a dead delivery after you fix your consumer.
  • Replay — resend any past event to your current endpoint without affecting production traffic.

Monitoring your endpoint

  • Alert on dead deliveries via the endpoint.delivery.failed event type or dashboard webhooks.
  • Alert on elevated retry rates — if more than 1% of deliveries are retrying, something is wrong.
  • Track p99 response time — if you consistently take >5 seconds, queue async and return 2xx immediately.

See also

On this page