Support email forwarding
The API receives Resend email.received events at
POST /integrations/resend/webhook. This is an integration endpoint, excluded
from customer API documentation and credit metering. It verifies the raw-body
Svix signature instead of requiring a customer API key.
Activate
- Deploy the API with the receiving handler.
- In Resend, add the public HTTPS webhook URL and subscribe only to
email.received. If receiving is not already enabled fortoolzerhub.com, configure the receiving domain and its MX records first; do not overwrite an existing mail provider's MX configuration without reviewing it. - Put the webhook's signing secret in
RESEND_WEBHOOK_SECRET. - Set
EMAIL_FORWARD_TO=thenetaji@proton.me. The default is empty, so inbound forwarding requires explicit configuration.RESEND_EMAIL_TOKENmust be a Resend API key with access to received mail and sending (Full access). - Restart the API with these environment values, then send a test message to
support@toolzerhub.comand verify delivery in Proton and Resend.
These steps have not been performed by adding the handler to the repository. Configuring the webhook does not change any outbound OTP or onboarding sender.
Behavior
Messages addressed to any mailbox at toolzerhub.com are forwarded, so the
receiving domain acts as a catch-all. The recipient is taken from server
configuration, never from webhook input. The forwarded sender is
Toolzer Hub Support <support@toolzerhub.com>, and Reply-To preserves the
original reply address (falling back to the original sender). Replying in Proton
targets the customer, using the account identity selected in Proton.
The reusable forwarding template adds an incoming-email header with the original From, To, CC, received time (UTC, when supplied), and subject above the original message in both HTML and plain text. Missing timestamps are labeled “Not provided”. Original CC addresses are visible in this header; they are not added as recipients of the internal forward. Add them explicitly when composing a reply to everyone.
HTML, text and attachments are preserved, including inline image Content-IDs. Attachment lists are paginated and downloads are bounded to 20 MiB total and 100 attachments. Unsupported/oversized messages fail visibly for investigation in the receiving dashboard instead of forwarding an incomplete message.
Messages from the support address or forwarding destination, messages already
marked as forwarded, and automatic replies (Auto-Submitted: auto-replied)
are ignored to prevent loops. Auto-generated support messages, such as forms
and receipts, are forwarded normally.
Other event types and inboxes are also acknowledged without sending anything.
Signatures must be within five minutes of the current time. Failed provider reads, downloads, or sends return a retryable error; message content and provider error bodies are not put in responses or application error diagnostics.
Forward sends use the stable Resend idempotency key
support-inbound/<received-email-id> and deterministic attachment content.
Resend retains idempotency keys for 24 hours. This prevents duplicates within
that window, including an ambiguous send followed by a retry; it is not a
permanent deduplication ledger. Replaying a previously sent event within that
window after changing the template can return an idempotency conflict because
the body changed; do not change its key to force another delivery. Replaying an
already-delivered event after that window can forward it again.