Delivery, retries and replays

Retries

A delivery fails when your endpoint does not answer 2xx within 10 seconds. Nexafon then retries with exponential backoff: about 30 seconds after the first failure, then doubling (1, 2, 4 minutes…) up to one attempt every 12 hours, with some jitter, for 72 hours after the first attempt. Each attempt sends the same event id with a higher Nexafon-Delivery-Attempt.

The first attempt starts within about a second of the event (p95).

Endpoints that keep failing

An endpoint that fails for the whole 72-hour window is turned off and the workspace’s owners are notified by email (“Webhooks to … are turned off”). Fix the receiver, send a test event, then turn the endpoint back on in Developers → Webhooks or with PATCH …/webhook-endpoints/{endpointId} and {"status": "active"}.

Delivery logs

GET …/webhook-endpoints/{endpointId}/deliveries lists every attempt: event, attempt number, status, response code, latency, the start of any error, and the next retry. The dashboard shows the same log.

Stored events and attempts contain customer data, so they are deleted after a retention period (a little over two weeks by default).

Replays

POST …/webhook-endpoints/{endpointId}/events/{eventId}/replay sends a stored event again, with its original id, to an active endpoint (a turned-off endpoint answers webhook_endpoint_disabled). Use it after fixing a bug in your receiver.

All of these operations are in the webhook endpoints reference; partners have the same under /api/v1/partner/webhook-endpoints (partner webhooks).