Webhook signature and replay window: idempotency so 02:00 is boring

Unsigned callbacks are not events. They are unauthenticated HTTP that happens to look like your payload. Teams that “accept first, verify later” discover the cost at 02:00: a replayed DLR, a duplicated STOP, or a second wallet debit that finance cannot unwind. Prepaid messaging makes the failure money-visible. The boring habits are signature verification on every request, a bounded replay window, and idempotency keys finance can read next to the ledger line.

IOSOR expects B2B integrations to be auditable: signed webhooks, rotatable secrets, client-safe errors that never dump foreign brands. Near USD 1,000+ monthly platform usage, correlation IDs and replay evidence become commercial review material — not just engineering hygiene. Pair this with webhooks and keys at launch and webhooks that survive launch.

Unsigned callbacks are not events

Verify the signature before you parse business fields. Reject missing, stale, or mismatched signatures with a client-safe error — do not process “anyway for the pilot.” A staging consumer that skips verification trains production to skip it. Catalog live for messaging does not mean your webhook URL is a public dump. If you cannot prove who signed the body, you do not have an event; you have a forged request.

Replay windows and why 02:00 happens

At-least-once delivery retries on timeout, 5xx, and ambiguous network loss. A late retry at 02:00 is normal. A replay window bounds how long a signed payload remains acceptable: too wide and an attacker replays an old STOP; too narrow and a legitimate retry looks like a forgery. Log window rejects separately from signature failures. See inbound webhook retries. Respond fast, persist first, process async — a handler that does CRM work before ACK is how you manufacture duplicates.

Idempotency that finance can read

The same event ID must produce the same end state. Extract the platform event/message ID — never invent a key from timestamp plus body. Return success on a known ID without re-debiting. Outbound sends need the same discipline — idempotency, retries, and money. Finance should explain every prepaid line against a status event. If a timeout causes a client retry storm, the ledger shows the damage first. Catalog in setup is not an excuse to skip idempotency “until Live.

Signature rotation without dual-accept chaos

Rotate secrets without a window where both old and new signatures are accepted forever. Plan overlap, then cut. Never paste a production secret into a support ticket.

Red flags

• Handler accepts unsigned bodies “for now”
• No replay window, or a window measured in weeks
• Status overwrite without timestamp comparison
• CRM/email side effects before ACK
• Shared production secret in chat
• Duplicate event IDs last month with nobody watching
• Client-facing errors that dump raw upstream codes

Start with IOSOR

Open your IOSOR console and inspect your active webhook endpoint settings for inbound delivery receipts and event callbacks. Set a tight signature verification replay window of five minutes and bind your handler strictly to the platform event ID. Test your endpoint against replayed payloads in staging to ensure duplicates return a 200 OK without triggering redundant business logic.

IOSOR takeaway

Unverified webhook handlers and missing replay windows turn routine network retries into security vulnerabilities and duplicate state changes. Bounding signature validity by timestamp and enforcing strict idempotency ensures that automated delivery attempts at 02:00 remain entirely predictable.