What is a webhook?
A webhook is an HTTP request sent by MailChannels when certain events in the email delivery process occur. By leveraging these events, you gain real-time insights into email delivery status, improve deliverability, and enhance your email sending strategies.Webhook management
MailChannels provides tools to create, retrieve, delete, and validate webhooks. The first step to receiving webhooks is to create a webhook.Creating a webhook
There are two ways to create a webhook: visit the webhooks page and click Create Webhook, or use the API. To create a webhook via the API, see the code examples below.Event notification format
Once configured, MailChannels will send event notifications to your webhook in the following format:Event fields
All event notifications include these common fields:email: The sender’sFromaddress.customer_handle: Your MailChannels account ID. Visible in the upper-right corner of the Console.timestamp: Unix timestamp of when the event occurred.event: Event type, such asprocessed,delivered, orhard-bounced.request_id: A unique identifier generated to track the original HTTP request.
The
customer_handle field lets a single webhook receiver handle events for multiple accounts. This is useful if you have
sub-accounts and want a single webhook receiver for all of them.It is important to make sure your webhook receiver can handle up to 1,000 items in each request body. Some libraries
may have default limits on the JSON body size or array length. Be sure to adjust those settings if necessary.
Retrieving webhook configuration
To view your current webhook configuration:Deleting a webhook
To stop receiving event notifications:Validating webhook configuration
To verify your current webhook setup, send a test event to each enrolled webhook:email: “test@mailchannels.com”.customer_handle: Your account ID.timestamp: Unix timestamp of the test event.event: “test”.request_id: Either provided by you or generated automatically.smtp_id: Generated automatically.
Best practices
- Verify the message signature.
- Ensure your webhook endpoint can handle concurrent requests.
- Process events asynchronously to avoid blocking the webhook receiver.
- Implement retry logic in case of temporary failures.
- Store raw event data before processing to allow for reprocessing if needed.
Storing webhook data
Treat webhook storage as part of your email system, not as an afterthought. A durable event table lets you answer support questions, rebuild derived state, and satisfy audit requirements. At minimum, store:- The full raw JSON payload.
- The event type.
- The event timestamp.
- The
customer_handle. - The
request_idandsmtp_id, when present. - Your processing status, such as
received,processed, orfailed.
Verifying message signatures
All webhooks are signed by default. There are three HTTP headers to consider during the signature verification process:- Content-Digest: hash of the message body
- Signature-Input: describes what parts of the message are signed, along with other data about the signing method
- Signature: the cryptographic signature
How to verify a message
Parse the Signature-Input header
The From this header you can extract:
Signature-Input header describes how the request was signed and which parts of it were covered. For example:- Signature name —
sig_1738775282. The matching entry in theSignatureheader uses the same name. - Covered components —
("content-digest"). Only theContent-Digestheader was signed. - Created —
1738868393, a Unix timestamp. - Algorithm —
ed25519. - Key ID —
mckey. Identifies which public key to use for verification.
Check the created timestamp
Reject signatures that are older than a short window (five minutes is a reasonable default) to defend against replay attacks.
Retrieve the public key
Fetch the public key from MailChannels using the Cache the response and reuse it for subsequent requests. You only need to refetch when you see a
keyid from step 1:keyid you haven’t
encountered before.Reconstruct the signing string
Rebuild the exact byte string that MailChannels signed, following the algorithm in RFC 9421, Section 2.5. For our example, the signing string is:The rules are:
- For each covered component, write the lowercased name in quotes, then
:, then the header value, on a single line. - Append a final
"@signature-params"line with the parenthesised component list followed by the remainingSignature-Inputparameters. - Join lines with a single
\nand do not include a trailing newline.

