Retries and the delivery log

At-least-once delivery

A delivery that does not return 2xx — or that times out — is retried with exponential backoff on a dedicated queue, so a slow endpoint of yours never holds up anyone else's.

That makes delivery at least once, never exactly once. Your endpoint must tolerate seeing the same event twice.

Dedupe on the delivery id

X-Evoriqa-Delivery — and the identical id field in the body — is minted once when the event is emitted and is byte-identical on every retry. It is the dedupe key.

const id = req.get("X-Evoriqa-Delivery");

// A set/table with a TTL is enough; the id is a UUID.
if (await seen.has(id)) {
  return res.status(200).end(); // already handled — acknowledge and stop
}
await seen.add(id, { ttlSeconds: 86_400 });
await handle(JSON.parse(req.body.toString("utf8")));
res.status(200).end();

The ts field is stable across retries too, so a duplicate is always correlatable with the original rather than looking like a fresh event.

Redirects

Deliveries follow up to two redirects, and each hop is re-validated against the same protections that block internal and private addresses. That exists so an endpoint behind an http → https upgrade still receives events instead of silently receiving none while appearing active.

Point the endpoint at its final HTTPS URL anyway — a redirect chain is one more thing to fail.

The delivery log

Settings → Webhooks shows recent delivery attempts across your endpoints, newest first, with the event name, the outcome, and the HTTP status your server returned.

Use it to answer the three questions that actually come up:

That last one is the most common real bug: work is done, the response is slow or errors, evoriqa retries, and the work happens again. Respond 2xx first, then process — and dedupe regardless.

Where to go next

• Signatures
• Events