Handle SendHog incoming and delivery events

SendHog documents a unified signed webhook endpoint for incoming mail and sending outcomes. It is not accurate to treat the service as outbound-only. Event registration, verification, and message-body retrieval remain separate tasks.

Register the intended events

1. Create an HTTPS receiver that preserves the request bytes needed by the documented verifier.
2. Use a credential with webhooks.manage to register it; an email.send key cannot manage subscriptions.
3. Subscribe only to the needed events, such as email.received, email.delivered, email.bounced, and email.complained.
4. Follow the current SendHog SDK/Standard Webhooks verification instructions. Older validators may not recognize the incoming-email event; check the documented minimum version.

Do not verify a SendHog signature with the MailKite webhook verifier. The event names can resemble one another while the authentication and payload contracts differ.

Persist events, then retrieve authorized content

Store authenticated events durably before acknowledgement. Incoming events identify stored messages; fetch body/original content separately under the required read permissions. A webhook-management key need not have every message-read capability.

Track message and recipient outcomes without letting a delayed delivery event clear a complaint or suppression. Duplicate/out-of-order events are normal. The documentation lists recognized event types, but that does not mean every account enables open/click tracking or every type applies to every message.

Test registration, invalid signatures, duplicate delivery, and one controlled incoming/sending event. Never use real verification codes or customer attachments as public debug payloads.

Source: SendHog webhooks, permissions, and event reference.