Retries and replays

Cevoid keeps trying a delivery until your endpoint accepts it or the retries run out. After that, you can send it again from Outbox: retry the same delivery, or replay the event as a new delivery.

• Return any 2xx status once you have stored the event. Result: Cevoid stops retrying it.
• Respond within 10 seconds and do slow work afterwards, for example in a job queue. A slower response counts as a timeout and is retried, even if you processed the event.
• Store webhook-id (the same value as id in the body) and skip an ID you have already processed. Result: a retry after a lost response cannot create a duplicate on your side.
• Order your own state by created_at or by the timestamps of the resource in data, not by arrival. Events for the same order or profile can arrive in any sequence.

Cevoid reads Retry-After as seconds or as an HTTP date, and only on the responses it retries.

A delivery gets up to seven attempts. After a failed attempt, Cevoid waits:

• Each wait varies by up to 20% either way, so endpoints recovering from an outage do not get every retry at the same moment.
• When your response has a Retry-After that asks for a later time than the schedule, Cevoid waits until then.
• Without Retry-After, the last attempt comes about 20.6 hours after the first. If it fails too, the delivery stops and shows as incomplete in Outbox.
• Every retry sends the same body with the same webhook-id to the URL of the first attempt, signed again with a new webhook-timestamp.

Open a delivery in Outbox or in the destination's Event deliveries, and use the menu of the delivery:

• Retry sends the same event again: the same webhook-id and the same body, to the URL of the first attempt. It is offered for a delivery that stopped for a reason it can recover from (see the table above), at most three times per delivery, and makes one attempt without automatic retries. The destination must be enabled.
• Replay as new delivery sends the original event again as a new delivery: the same id, webhook-id, created_at and body, to the destination's current URL, with automatic retries of its own. A receiver that already processed the event skips it when it deduplicates on webhook-id. The destination must be enabled, and its URL must pass the safety check.

Use Retry after an outage or a fixed secret. Use a replay when the delivery cannot be retried or after you moved the endpoint.

Outbox lists every delivery and every attempt of it: when it ran, the HTTP status, how long it took and why it stopped. For each attempt it keeps:

• the first 2,048 bytes of your response body, with email addresses, bearer tokens and values of fields such as password, secret and token masked;
• your response's content-type, retry-after and x-request-id headers.

Return an x-request-id header to match an attempt with your own logs.

• Repeated events: deduplicate on webhook-id. A slow response is the most common cause: answer within 10 seconds.
• Retry is not offered: the delivery stopped on a 3xx or 4xx other than 401 and 403, or it was retried three times already. Replay it.
• Delivery stopped without retries: check the status in Outbox. 401, 403 and other 4xx statuses stop a delivery at once.
• Replay is refused: enable the destination, and check that its URL still resolves to a public address. A delivery that never made an attempt has no body to replay.