Skip to main content

​
Overview

Instead of delivering filtered inbound emails to a mail server, you can configure a domain to deliver them as HTTP webhook requests to your application. When an email arrives for your domain, we’ll send a POST request to your configured endpoint with the full email payload. This is ideal for applications that need to process incoming emails programmatically — such as support ticket systems, CRM platforms, or automated workflows.
This is different from event webhooks, which notify you about email events (delivered, bounced, etc.). Inbound webhooks deliver the actual email content to your application.

​
Setting Up Webhook Delivery

1

Navigate to Inbound Settings

Log in to the JetEmail Dashboard and go to Inbound and select your domain.
2

Set Delivery Type to Webhook

In your domain settings, change the Delivery Type to Webhook.
3

Configure Your Endpoint

Enter your Webhook URL — the HTTPS endpoint where you want to receive emails (e.g. https://app.example.com/inbound).
4

Configure Authentication (Optional)

For additional security, configure a Webhook Secret to sign requests so you can verify authenticity.

​
Request Format

When an email arrives, we send a POST request to your webhook URL with the following headers:
HeaderDescription
Content-Typeapplication/json
X-Webhook-IDUnique job identifier
X-Webhook-TimestampUnix timestamp of the delivery attempt
X-Webhook-SignatureHMAC-SHA256 signature (when webhook secret is configured)
The request body contains a JSON payload with the full email data, including sender, recipients, subject, body, headers, and any attachments. See Payload Reference for the complete payload structure.

​
Responding to Webhooks

Your endpoint should respond with an HTTP status code to indicate success or failure:
Status CodeBehavior
2xxSuccess — email is acknowledged and delivery is complete
429Rate limited — we’ll retry with backoff
5xxServer error — we’ll retry with backoff
4xx (except 429)Permanent failure — email is not retried
Your endpoint must respond within the configured timeout (default 30 seconds) or the request will timeout and be retried.

​
Retry Strategy

If delivery fails, we’ll retry with exponential backoff:
AttemptDelay
1Immediate
230 seconds
32 minutes
410 minutes
51 hour
64 hours
7+Moved to dead letter queue
The maximum number of retry attempts is configurable per domain (default: 3). After all retries are exhausted, the email is moved to the dead letter queue where it is retained for 7 days.
4xx responses (except 429) are treated as permanent failures and are not retried. Make sure your endpoint returns a 5xx status if you want the delivery to be retried.