Verify and persist Loops delivery webhooks

Configure the events you actually need in Loops Settings → Webhooks and store the signing secret securely. The current webhook documentation describes signing, replay timing, retries, and endpoint failure behavior.

Verify before accepting work

1. Preserve the original body and the webhook-id, webhook-timestamp, and webhook-signature headers.
2. Use the currently documented verification implementation/library with the endpoint’s signing secret and replay tolerance.
3. Reject verification failures before parsing the event into business actions.
4. Persist the authenticated event or queue durable work before returning 2xx, then process it asynchronously.

Use webhook-id to deduplicate deliveries and make downstream effects idempotent too. Do not substitute a MailKite verifier merely because both systems sign events.

Test retry and endpoint operations

Exercise a duplicate, invalid signature, and temporary receiver failure. Loops documents bounded exponential-backoff retries and automatic endpoint disabling after sustained failures; monitor the endpoint state and recovery path rather than assuming infinite replay.

Subscribe only to event types applicable to your email workflow. Transactional emails do not gain open/click tracking just because other Loops traffic supports those events.

A delivery webhook reports an outgoing message outcome, not a new reply body. For incoming replies, use an explicit receiving mailbox/provider path such as a separately verified MailKite address.