# Idempotency, retries and delivery order

**Sending:** always send an `Idempotency-Key` on POST /v1/messages. **You generate it**, we don't hand it to you: a fresh UUID v4 per message you want to send (not per HTTP attempt — reusing it on a retry is the whole point). A retry with the same key returns the same record (200) instead of duplicating. The source of truth is MariaDB (we persist before enqueuing), so a 202 is never lost even if Redis goes down.

**Delivery (webhooks):** retries with backoff **1m → 5m → 30m → 2h → 6h** (5 attempts). The `X-Connect-Delivery-Id` is **stable across retries** → deduplicate on it. After 20 consecutive failures the endpoint is **auto-disabled** (critical alert) and you re-enable it from the panel.

**Order:** delivery order is NOT guaranteed (retries + concurrency). Order it yourself by `createdAt` (ISO-8601 Z) + `sequence` (monotonic per connection; 0 when `connection` is null).

## Notes

- Your endpoint must be **idempotent**: the same delivery can arrive more than once.