Retry and idempotency policy
Audience: operators redriving failed deliveries and engineers building Notify channel connectors.
This page defines how Notify retries failed deliveries and how idempotency keys guarantee that retries and dead-letter redrives never duplicate a send.
Tracking reference: NR5.
Identity and deduplication
| Field | Definition |
|---|---|
delivery_id | UUIDv7, unique per delivery attempt chain. |
dedupe_key | hash(event_id + rule_id + channel_id) — stable across retries of the same logical delivery. |
Backoff schedule
- Exponential backoff with jitter: base
2s, factor2. - Maximum of
5attempts. - Cap of
5 minutesbetween attempts.
Idempotency guarantees
- Connectors must be idempotent: every retry reuses the same
dedupe_keyand must not produce a duplicate send. - Out-of-order acknowledgements are ignored; only a monotonically increasing
attemptis accepted. - Retry outcomes are recorded in delivery receipts, including the attempt count and the failure reason.