Is MailWebhook a drop-in replacement for SendGrid Inbound Parse?

No. MailWebhook is a different inbound email webhook workflow. SendGrid Inbound Parse posts SendGrid parse payloads to your URL. MailWebhook connects supported mailbox sources, runs route rules and pipelines, then posts signed JSON route output to your endpoint.

Can I keep my existing SendGrid receiver code?

Not unchanged. Existing receiver code built around SendGrid multipart fields or raw MIME should be adapted to accept MailWebhook's JSON payload and signature header. The upside is that route mapping can remove a lot of receiver-side transformation code.

Does MailWebhook support existing Gmail or Microsoft 365 mailboxes?

Yes. MailWebhook supports Gmail and Google Workspace mailboxes, Microsoft 365/Office 365/Outlook mailbox workflows, IMAP mailboxes, and MailWebhook-hosted mailboxes.

Does MailWebhook receive email through MX records like SendGrid Inbound Parse?

MailWebhook is not positioned here as a SendGrid-style custom MX receiver. The supported page claim is mailbox intake through Gmail, Microsoft 365, IMAP, or MailWebhook-hosted mailbox workflows.

What happens to attachments?

MailWebhook webhook payloads include attachment metadata such as id, filename, content type, size, inline status, and checksum when available. Attachment file bytes are fetched separately through a signed attachment URL.

Does MailWebhook send JSON or multipart form data?

MailWebhook sends JSON. Endpoint delivery uses POST with Content-Type: application/json, and the request body is exactly the selected route pipeline output.

How does MailWebhook help with duplicate webhook processing?

Each delivery includes an X-Idempotency-Key header so your receiver can dedupe processing for a given message and route.

Does SendGrid Inbound Parse support security?

Yes. SendGrid documents Inbound Parse security policies with ECDSA signature verification, OAuth, or both. MailWebhook uses its own X-MailWebhook-Signature contract plus optional endpoint static headers.

Can I test MailWebhook before switching?

Yes. Start with the free plan, create a route, send test email through a supported mailbox source, compare the JSON output with your current receiver expectations, and switch the source or forwarding path only after the downstream behavior is verified.

SendGrid Inbound Parse Alternative

SendGrid Inbound Parse alternative for structured email webhooks

MailWebhook turns inbound email from Gmail, Microsoft 365, IMAP, or hosted mailboxes into signed JSON webhook events with route-level mapping, attachment metadata, idempotency keys, event inspection, and replay.

Start free View email webhook API

Built for teams comparing SendGrid Inbound Parse, email parser webhooks, and custom inbound email receivers.

SendGrid Inbound Parse
  -> MX for parse.example.com
  -> multipart or raw MIME POST
  -> receiver-side parsing and mapping

MailWebhook
  -> Gmail, Microsoft 365, IMAP, or hosted mailbox
  -> route rules and JSON mapping
  -> signed JSON webhook POST

Looking for SendGrid Event Webhook? This page covers inbound email parsing and email-to-webhook workflows.

What is a SendGrid Inbound Parse alternative?

A SendGrid Inbound Parse alternative receives inbound email and sends it to your application without requiring your team to build all parsing, routing, mapping, attachment handling, and webhook delivery logic yourself.

SendGrid Inbound Parse is built around a receiving domain or subdomain that points MX records at SendGrid, then posts parsed email data to your URL. MailWebhook takes a different path: connect Gmail, Microsoft 365, IMAP, or a MailWebhook-hosted mailbox, define route rules, choose generic or custom JSON, and receive signed webhook POSTs your backend can process directly.

This page is about SendGrid Inbound Parse for incoming email. It is not about SendGrid Event Webhook events such as delivered, opened, clicked, bounced, or spam-report notifications.

Compare the webhook payloads

When SendGrid Inbound Parse is still the simple choice

Dedicated parse domain

Use SendGrid Inbound Parse when you want email sent to a dedicated domain or subdomain to be accepted by SendGrid and posted to your receiver.

Existing SendGrid stack

Use it when your team already manages SendGrid settings, parse APIs, and receiver code, and the current multipart or raw MIME workflow is working.

Receiver-owned parsing

Use it when you prefer to handle mapping, extraction, attachment file parts, retries, and downstream adaptation inside your own application.

MailWebhook is for a different buyer: teams that want the inbound email workflow to arrive as structured JSON webhook events from practical mailbox sources, with less custom parsing code after receipt.

Why developers look beyond classic inbound parse

Existing mailbox is the source of truth

The workflow already lives in Gmail, Microsoft 365, Outlook, IMAP, or a shared inbox. Moving it to a dedicated parse subdomain can be operationally awkward.

The app wants JSON, not parser glue

Receiver code often ends up normalizing multipart fields, raw MIME, sender fields, attachments, headers, and business-specific payloads before the app can use the message.

Payload shape matters

Generic parsed fields are useful, but many workflows need a route-specific JSON contract for a CRM, ERP, AI agent, ticketing system, or internal API.

Operations matter after delivery fails

Teams need event history, attempt details, idempotency, and replay when a downstream receiver has an outage or bad deploy.

SendGrid Inbound Parse vs MailWebhook

Evaluation area	SendGrid Inbound Parse	MailWebhook
Primary fit	Parse inbound email sent to a configured receiving domain or subdomain.	Turn inbound messages from Gmail, Microsoft 365, IMAP, or hosted mailboxes into route-shaped JSON webhooks.
Intake model	MX-based receiving domain or subdomain pointed to SendGrid.	OAuth mailboxes, IMAP mailboxes, or MailWebhook-hosted mailboxes.
Webhook body	Default multipart/form-data payload, with raw MIME option.	application/json body that is exactly the selected route pipeline output.
Payload shape	SendGrid-owned parse fields; receiver usually adapts fields into the app's contract.	Documented generic JSON or custom JSON output configured per route.
Attachments	Can arrive as multipart file parts or inside raw MIME.	Attachment metadata in JSON; file bytes fetched by signed URL when needed.
Mapping before delivery	Receiver typically handles app-specific mapping after POST.	Route pipeline can emit the JSON shape the receiver expects before POST.
Existing mailbox support	Not the primary model in public Inbound Parse docs.	Gmail, Microsoft 365/Outlook, IMAP, and hosted mailbox workflows.
Security	Supports Inbound Parse security policies with ECDSA signature verification, OAuth, or both.	Includes X-MailWebhook-Signature, X-Idempotency-Key, and optional endpoint static headers.
Failure recovery	Retries 5XX responses and drops messages after the documented retry window.	Event history, delivery attempts, automatic retries, and replay for receiver-side recovery workflows.
Best reason to choose	You want a SendGrid-hosted parse endpoint for a dedicated receiving domain.	You want structured inbound email events with route rules, JSON mapping, idempotency, and replay.

Primary fit

SendGrid Inbound Parse: Parse inbound email sent to a configured receiving domain or subdomain.
MailWebhook: Turn inbound messages from Gmail, Microsoft 365, IMAP, or hosted mailboxes into route-shaped JSON webhooks.

Intake model

SendGrid Inbound Parse: MX-based receiving domain or subdomain pointed to SendGrid.
MailWebhook: OAuth mailboxes, IMAP mailboxes, or MailWebhook-hosted mailboxes.

Webhook body

SendGrid Inbound Parse: Default multipart/form-data payload, with raw MIME option.
MailWebhook: application/json body that is exactly the selected route pipeline output.

Payload shape

SendGrid Inbound Parse: SendGrid-owned parse fields; receiver usually adapts fields into the app's contract.
MailWebhook: Documented generic JSON or custom JSON output configured per route.

Attachments

SendGrid Inbound Parse: Can arrive as multipart file parts or inside raw MIME.
MailWebhook: Attachment metadata in JSON; file bytes fetched by signed URL when needed.

Mapping before delivery

SendGrid Inbound Parse: Receiver typically handles app-specific mapping after POST.
MailWebhook: Route pipeline can emit the JSON shape the receiver expects before POST.

Existing mailbox support

SendGrid Inbound Parse: Not the primary model in public Inbound Parse docs.
MailWebhook: Gmail, Microsoft 365/Outlook, IMAP, and hosted mailbox workflows.

Security

SendGrid Inbound Parse: Supports Inbound Parse security policies with ECDSA signature verification, OAuth, or both.
MailWebhook: Includes X-MailWebhook-Signature, X-Idempotency-Key, and optional endpoint static headers.

Failure recovery

SendGrid Inbound Parse: Retries 5XX responses and drops messages after the documented retry window.
MailWebhook: Event history, delivery attempts, automatic retries, and replay for receiver-side recovery workflows.

Best reason to choose

SendGrid Inbound Parse: You want a SendGrid-hosted parse endpoint for a dedicated receiving domain.
MailWebhook: You want structured inbound email events with route rules, JSON mapping, idempotency, and replay.

From parsed email fields to route-shaped JSON

Classic inbound parse receiver work

Inbound parse POST
  fields: headers, from, to, subject, text, html
  metadata: envelope, charsets, SPF, spam_score
  attachments: count, metadata, file parts or raw MIME

Receiver code
  parse -> normalize -> extract -> map -> dedupe -> process

A traditional inbound parse receiver often starts by reading fields such as headers, text, HTML, envelope, spam results, character sets, attachment metadata, and file parts. Then your app maps those values into the object the downstream system actually expects.

MailWebhook route output

Option A: generic JSON payloadmailwebhook.generic@1

{
  "schema": { "name": "mailwebhook.generic", "version": "1" },
  "event": { "id": "6ff49aa1-7050-4ad1-95d9-2711f2ca7e88", "created_at": "2026-06-27T10:14:32Z" },
  "message": {
    "message_id": "<invoice-1042@vendor.example>",
    "subject": "Invoice 1042",
    "from": [{ "email": "billing@vendor.example" }]
  },
  "body": {
    "text": "Please review invoice 1042.",
    "attachments": [{ "filename": "invoice-1042.pdf", "size": 93259 }]
  },
  "meta": { "source": "gmail", "received_at": "2026-06-27T10:14:32Z" }
}

Option B: custom JSON bodymap.custom_json

{
  "kind": "invoice",
  "message_id": "<invoice-1042@vendor.example>",
  "vendor": {
    "email": "billing@vendor.example",
    "domain": "vendor.example"
  },
  "subject": "Invoice 1042",
  "attachment": {
    "filename": "invoice-1042.pdf",
    "content_type": "application/pdf",
    "size": 93259
  }
}

MailWebhook moves the mapping into the route. Your receiver can accept the documented generic mailwebhook.generic@1 payload (Option A) with its fixed schema, event, message, body, and meta envelope, or a custom JSON body shaped before delivery (Option B). The custom fields kind, vendor.domain, and attachment are route output created by your mapping rules, not automatic universal fields.

Generic JSON docs Custom JSON docs Email to JSON

How to move a SendGrid Inbound Parse workflow to MailWebhook

MailWebhook is not a drop-in endpoint for existing SendGrid parse payloads. Treat migration as a small workflow redesign: choose the mailbox source, define route rules, map the payload your receiver wants, then update the downstream receiver to accept signed JSON.

1
Choose the intake source
Use Gmail, Microsoft 365/Outlook, IMAP, or a MailWebhook-hosted mailbox. For existing business addresses, use provider forwarding rules, groups, distribution lists, or mailbox connection where they fit your setup.
2
Create the endpoint
Register the public HTTPS URL that should receive MailWebhook POSTs, including any static authorization headers your receiver needs.
3
Recreate the routing logic
Use route rules such as sender, recipient, subject, headers, attachment MIME type, and boolean combinators to match the messages that should trigger the workflow.
4
Map the payload
Start with map.generic_json or use map.custom_json to emit the exact JSON your receiver expects.
5
Update receiver verification
Verify X-MailWebhook-Signature against the raw request body and use X-Idempotency-Key to dedupe processing.
6
Run both paths during cutover
Send test messages through the MailWebhook route, compare receiver output, then move forwarding or mailbox routing when the downstream behavior matches.

Create your first route

Use the mailbox source that matches the workflow

Gmail and Google Workspace

Connect Gmail mailboxes, optionally scope by Gmail label, and deliver normalized messages as webhook events.

Gmail to webhook

Microsoft 365, Office 365, and Outlook

Connect Outlook mailbox workflows, including shared mailbox targeting when delegated access allows it.

Microsoft 365 to webhook

IMAP

Connect existing IMAP mailboxes and monitor a configured folder without running your own poller.

IMAP to webhook

Hosted mailbox

Use a MailWebhook-hosted address when a dedicated intake inbox is cleaner than connecting an existing mailbox.

Mailbox docs

This is the main reason to choose MailWebhook over a classic inbound parse flow: the inbox can stay where the business process already happens.

Match messages, then send the JSON your app expects

Route rule

{
  "to_emails": ["ap@company.com"],
  "from_domains": ["vendor.example"],
  "subject_contains": ["invoice", "receipt"],
  "attachments_mime": ["application/pdf"]
}

Custom mapper

{
  "steps": [
    {
      "name": "map.custom_json",
      "args": {
        "version": "v1",
        "vars": [
          {
            "name": "sender",
            "expr": { "var": "message.from[0].email" }
          }
        ],
        "output": {
          "message_id": { "var": "message.message_id" },
          "subject": { "var": "message.subject" },
          "sender": { "var": "vars.sender" },
          "attachments": { "var": "message.attachments" }
        }
      }
    }
  ]
}

Routes let you decide which messages become webhook events. The pipeline then decides what JSON gets delivered. That keeps downstream receiver code focused on business logic instead of mailbox parsing, payload cleanup, and one-off adapter code.

Route rules docs Custom JSON mapper docs

Attachment metadata in the webhook, file bytes on demand

SendGrid Inbound Parse can deliver attachments as multipart file parts or as part of a raw MIME payload, depending on configuration. MailWebhook uses a different contract: webhook JSON includes attachment metadata, and your backend fetches file bytes separately through a signed attachment URL when it needs the file.

Attachment metadata

{
  "id": "9f5a1ded-538d-4f5f-a7a9-d3eacf9e58a0",
  "filename": "invoice-1042.pdf",
  "content_type": "application/pdf",
  "size": 93259,
  "is_inline": false,
  "sha256": "059a0f5260487bbe663994de1fd641401fec76ac9f6bddfe5b53ae60d4bb2d86"
}

Attachment URL endpoint

GET /v1/messages/{message_id}/attachments/{attachment_id}/url

This keeps normal webhook deliveries smaller and lets receivers download attachment bytes only for workflows that need them.

Read attachment URL docs

A webhook contract built for production receivers

SendGrid Inbound Parse supports its own security policy model, including signature verification and OAuth options. MailWebhook uses a MailWebhook-specific receiver contract: JSON POST body, signature header, idempotency key, static endpoint headers, event history, delivery attempts, and replay.

Verify the sender with X-MailWebhook-Signature.
Use X-Idempotency-Key to make receiver processing safe to retry.
Include endpoint static headers for bearer tokens, API keys, or receiver-specific auth.
Inspect event history and delivery attempts when the receiver rejects or times out.
Replay an event after fixing downstream code or infrastructure.
Keep private, loopback, link-local, reserved, and multicast endpoint destinations out of production webhook targets.

Read endpoint docs

Where MailWebhook usually beats parser glue

Accounts payable intake

Turn invoices and receipts from vendor inboxes into JSON events for ERP, approval, or finance workflows.

Support and customer intake

Send shared inbox messages to ticketing, triage, or internal workflow APIs with predictable sender and body fields.

AI agent inboxes

Give agents structured email events instead of asking them to poll a mailbox or parse raw MIME.

AI agent email intake

Legacy notification bridges

Convert email-only alerts from vendors, appliances, and older systems into HTTP events.

Document routing

Use attachment metadata, sender rules, and route mapping to decide which downstream service should fetch or process a file.

Which one should you use?

Use SendGrid Inbound Parse when

You already route a dedicated parse domain or subdomain through SendGrid.
You want SendGrid to receive email directly for that domain.
Your receiver is already built around SendGrid's multipart or raw MIME parse payload.
Your application should own all app-specific mapping after the POST.
You want attachment file parts delivered inside the inbound parse request.

Use MailWebhook when

The source is an existing Gmail, Microsoft 365, Outlook, IMAP, or hosted mailbox workflow.
Your receiver wants application/json, not multipart parser plumbing.
You want route-specific JSON mapping before delivery.
You need signatures, idempotency keys, delivery attempts, and replay in the same workflow.
You want attachment metadata in JSON and signed file download only when needed.

Start free, scale when you need to

The Free plan includes 300 emails/month at no cost. Paid plans start at $29/per month with a 30-day free trial.

See full pricing

HMAC-signed webhook delivery
Automatic retries with backoff
Event inspector and replay
Idempotency keys for safe dedupe

Frequently asked questions

Is MailWebhook a drop-in replacement for SendGrid Inbound Parse?: No. MailWebhook is a different inbound email webhook workflow. SendGrid Inbound Parse posts SendGrid parse payloads to your URL. MailWebhook connects supported mailbox sources, runs route rules and pipelines, then posts signed JSON route output to your endpoint.
Can I keep my existing SendGrid receiver code?: Not unchanged. Existing receiver code built around SendGrid multipart fields or raw MIME should be adapted to accept MailWebhook's JSON payload and signature header. The upside is that route mapping can remove a lot of receiver-side transformation code.
Does MailWebhook support existing Gmail or Microsoft 365 mailboxes?: Yes. MailWebhook supports Gmail and Google Workspace mailboxes, Microsoft 365/Office 365/Outlook mailbox workflows, IMAP mailboxes, and MailWebhook-hosted mailboxes.
Does MailWebhook receive email through MX records like SendGrid Inbound Parse?: MailWebhook is not positioned here as a SendGrid-style custom MX receiver. The supported page claim is mailbox intake through Gmail, Microsoft 365, IMAP, or MailWebhook-hosted mailbox workflows.
What happens to attachments?: MailWebhook webhook payloads include attachment metadata such as id, filename, content type, size, inline status, and checksum when available. Attachment file bytes are fetched separately through a signed attachment URL.
Does MailWebhook send JSON or multipart form data?: MailWebhook sends JSON. Endpoint delivery uses POST with Content-Type: application/json, and the request body is exactly the selected route pipeline output.
How does MailWebhook help with duplicate webhook processing?: Each delivery includes an X-Idempotency-Key header so your receiver can dedupe processing for a given message and route.
Does SendGrid Inbound Parse support security?: Yes. SendGrid documents Inbound Parse security policies with ECDSA signature verification, OAuth, or both. MailWebhook uses its own X-MailWebhook-Signature contract plus optional endpoint static headers.
Should I use this page if I searched for SendGrid Event Webhook?: Probably not. SendGrid Event Webhook refers to SendGrid sending events such as delivered, opened, clicked, bounced, or spam report. This page is about inbound email parsing and inbound email-to-webhook workflows.
Can I test MailWebhook before switching?: Yes. Start with the free plan, create a route, send test email through a supported mailbox source, compare the JSON output with your current receiver expectations, and switch the source or forwarding path only after the downstream behavior is verified.

Replace parser glue with signed JSON email webhooks

Connect a mailbox source, define the route, shape the JSON, and send your application a webhook payload it can process without another inbound parse adapter.

Start free View email-to-webhook overview