> ## Documentation Index
> Fetch the complete documentation index at: https://jetemail.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Started

> Deliver inbound emails to your application via webhooks

## 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.

<Info>
  This is different from [event webhooks](/docs/webhooks/getting-started), which notify you about email events (delivered, bounced, etc.). Inbound webhooks deliver the **actual email content** to your application.
</Info>

## Setting Up Webhook Delivery

<Steps>
  <Step title="Navigate to Inbound Settings">
    Log in to the [JetEmail Dashboard](https://dash.jetemail.com) and go to **Inbound** and select your domain.
  </Step>

  <Step title="Set Delivery Type to Webhook">
    In your domain settings, change the **Delivery Type** to **Webhook**.
  </Step>

  <Step title="Configure Your Endpoint">
    Enter your **Webhook URL** — the HTTPS endpoint where you want to receive emails (e.g. `https://app.example.com/inbound`).
  </Step>

  <Step title="Configure Authentication (Optional)">
    For additional security, configure a **Webhook Secret** to sign requests so you can [verify authenticity](/docs/inbound/webhooks/security).
  </Step>
</Steps>

## Request Format

When an email arrives, we send a POST request to your webhook URL with the following headers:

| Header | Description |
| - | - |
| `Content-Type` | `application/json` |
| `X-Webhook-ID` | Unique job identifier |
| `X-Webhook-Timestamp` | Unix timestamp of the delivery attempt |
| `X-Webhook-Signature` | HMAC-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](/docs/inbound/webhooks/payload) for the complete payload structure.

## Responding to Webhooks

Your endpoint should respond with an HTTP status code to indicate success or failure:

| Status Code | Behavior |
| - | - |
| `2xx` | Success — email is acknowledged and delivery is complete |
| `429` | Rate limited — we'll retry with backoff |
| `5xx` | Server error — we'll retry with backoff |
| `4xx` (except 429) | Permanent failure — email is not retried |

<Warning>
  Your endpoint must respond within the configured timeout (default **30 seconds**) or the request will timeout and be retried.
</Warning>

## Retry Strategy

If delivery fails, we'll retry with exponential backoff:

| Attempt | Delay |
| - | - |
| 1 | Immediate |
| 2 | 30 seconds |
| 3 | 2 minutes |
| 4 | 10 minutes |
| 5 | 1 hour |
| 6 | 4 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.

<Tip>
  **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.
</Tip>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.