Why an Email Parsing API Matters for Your Stack
Inbound email is a first-class integration surface for modern SaaS platforms. A robust email parsing API turns raw SMTP traffic into structured data you can trust, then delivers it via REST or webhook so your application can act in real time. Product feedback loops, support ticketing, billing replies, automated approvals, and user-generated content all rely on accurate MIME parsing, resilient delivery, and a developer experience that removes operational friction.
In this comparison, we look specifically at the email-parsing-api capabilities of two options developers often evaluate: Mailchimp's Mandrill Inbound and MailParse. We focus on how messages are parsed, how data is delivered to your systems via webhook or REST polling, how each platform handles edge cases, and what the developer workflow looks like in practice.
If you are planning an inbound processing pipeline for a product launch or a migration, it pays to scrutinize MIME fidelity, attachment handling, idempotency, retries, and the ergonomics of the APIs you will live with every day.
How MailParse Handles Email Parsing API
MailParse is designed to provide instant email addresses, parse MIME into structured JSON, and deliver via webhook or REST polling. The goal is predictable structure, complete access to raw artifacts, and simple operational controls that fit into existing infrastructure.
Creating Inboxes and Routes
- Instant inboxes: create disposable or long-lived addresses with a REST call. Useful for per-user routing or one-off automations.
- Custom domains: bring your domain and configure MX records to the platform, then create routes based on recipient, subaddress, or regex patterns.
- Route targets: set a primary webhook URL plus optional dead letter queue or fallback REST polling for redundancy.
Webhook Delivery
When a message arrives, the platform POSTs well-structured JSON to your webhook. Non-2xx responses trigger retries with exponential backoff. Each delivery includes a deterministic message_id for idempotency, an attempt counter, and an HMAC signature header so you can verify authenticity.
{
"event": "inbound",
"message_id": "msg_01hv3g9b3y4q4p9a6c",
"received_at": "2026-04-22T13:37:12Z",
"envelope": {
"mail_from": "alice@example.com",
"rcpt_to": ["support@yourdomain.test"]
},
"headers": {
"subject": "Re: Order #12345",
"message-id": "<abc123@example.com>",
"to": "Support <support@yourdomain.test>",
"from": "Alice <alice@example.com>",
"date": "Tue, 22 Apr 2026 13:36:58 +0000"
},
"security": {
"dkim": {"result": "pass"},
"spf": {"result": "pass"},
"dmarc": {"result": "pass"}
},
"parsed": {
"text": "Thanks for the update.\n",
"html": "<p>Thanks for the update.</p>",
"attachments": [
{
"id": "att_01hv3g9c",
"filename": "invoice.pdf",
"content_type": "application/pdf",
"size": 183423
}
],
"parts": [
{"content_type": "text/plain; charset=utf-8", "size": 21},
{"content_type": "text/html; charset=utf-8", "size": 43}
]
},
"raw": {
"id": "raw_01hv3g9d",
"size": 23451
}
}Security headers are signed using an API key derived secret. You can verify with any HMAC SHA-256 library.
REST Polling and Artifact Access
- Message listing:
GET /v1/messages?status=delivered&limit=50 - Message detail:
GET /v1/messages/{message_id} - Raw MIME:
GET /v1/messages/{message_id}/raw - Attachment download:
GET /v1/messages/{message_id}/attachments/{attachment_id} - Ack endpoint for manual control:
POST /v1/messages/{message_id}/ack
This dual-mode design lets teams combine webhooks for real time with REST for recovery, reprocessing, and audits.
MIME Fidelity and Edge Cases
- Nested multipart handling including multipart/alternative inside multipart/mixed.
- Character set normalization to UTF-8 with original charsets preserved in metadata.
- Inline image extraction with content-id mapping in the HTML.
- TNEF winmail.dat extraction when possible, passed through when not.
- S/MIME and PGP parts preserved with content types intact so you can choose how to handle them.
How Mandrill Inbound Handles Email Parsing API
Mandrill Inbound is part of Mailchimp's transactional email offering. You configure an inbound domain, point MX records to Mandrill, then create routes that map recipients to a webhook URL. When a message arrives, Mandrill posts JSON to your webhook with the parsed content along with optional raw MIME.
Inbound Setup
- Requires a Mailchimp account with Mandrill enabled.
- Inbound domain must point MX to Mandrill's servers.
- Routes are based on the full recipient address or a pattern, one route maps to one webhook URL.
Webhook Format
Mandrill delivers inbound events to your endpoint as a form-encoded parameter named mandrill_events that contains a JSON array. Each event has a msg object with headers, text, html, attachments, and optionally raw_msg if configured.
POST Content-Type: application/x-www-form-urlencoded
mandrill_events=[{
"event": "inbound",
"ts": 1713783432,
"msg": {
"raw_msg": "Return-Path: ...",
"headers": {"Subject": "Re: Order #12345", "To": "support@yourdomain.test"},
"text": "Thanks for the update.\n",
"html": "<p>Thanks for the update.</p>",
"from_email": "alice@example.com",
"from_name": "Alice",
"email": "support@yourdomain.test",
"subject": "Re: Order #12345",
"spam_report": {"score": 0.1},
"dkim": {"signed": true, "valid": true},
"spf": {"result": "pass"},
"attachments": {
"invoice.pdf": {
"name": "invoice.pdf",
"type": "application/pdf",
"content": "JVBERi0xLjQKJcTl8uXr...base64...",
"base64": true
}
}
}
}]Mandrill includes an X-Mandrill-Signature header so you can verify the webhook using your webhook key. A 200 OK signals successful receipt. Non-200 responses are retried. While Mandrill parses common multipart structures, some advanced conversions, like TNEF decoding, may be left as attachments for your application to handle.
Side-by-Side Comparison of Email Parsing API Features
| Capability | MailParse | Mandrill Inbound |
|---|---|---|
| Account model | Standalone developer-focused service | Requires Mailchimp account with Mandrill |
| Delivery methods | Webhook plus REST polling for audits and recovery | Webhook primary, no native REST polling for inbound events |
| Raw MIME access | First-class resource via REST and webhook metadata | Available as raw_msg when enabled |
| Attachment handling | Attachment metadata plus direct download endpoints | Base64 attachment map in webhook payload |
| Signature verification | HMAC SHA-256 header on each webhook attempt | X-Mandrill-Signature header |
| Idempotency | Deterministic message_id and repeatable REST fetches |
Event array with timestamps, dedupe logic left to the consumer |
| Inbox provisioning | Instant inbox creation via REST, plus custom domains | Inbound domain and route configuration inside Mandrill |
| MIME fidelity | Nested multipart preservation with charset normalization | Common multipart support, advanced formats may be passed through |
| Retries and backoff | Exponential backoff with final dead letter option | Retries on non-200 responses |
| Operational controls | Ack endpoints, replay by ID, selective redelivery | Webhook-only reception, replay requires external tooling |
Code Examples: Developer Experience Side by Side
Webhook Handler for the Platform
// Node.js Express - verify signature and ack
import crypto from "crypto";
import express from "express";
const app = express();
app.use(express.json());
function verifySignature(req, secret) {
const signature = req.headers["x-signature"];
const body = JSON.stringify(req.body);
const hmac = crypto.createHmac("sha256", secret).update(body).digest("hex");
return signature === hmac;
}
app.post("/inbound", async (req, res) => {
if (!verifySignature(req, process.env.WEBHOOK_SECRET)) {
return res.status(401).send("invalid signature");
}
const evt = req.body;
// Idempotent processing by message_id
await processMessage(evt.message_id, evt);
return res.status(200).send("ok");
});
app.listen(3000);REST Polling and Artifact Download
# Fetch recent messages, then download raw MIME and attachments
curl -H "Authorization: Bearer <API_KEY>" \
"https://api.example.test/v1/messages?status=delivered&limit=10"
# Get message detail
curl -H "Authorization: Bearer <API_KEY>" \
"https://api.example.test/v1/messages/msg_01hv3g9b3y4q4p9a6c"
# Download raw MIME
curl -H "Authorization: Bearer <API_KEY>" \
-o message.eml \
"https://api.example.test/v1/messages/msg_01hv3g9b3y4q4p9a6c/raw"
# Download attachment
curl -H "Authorization: Bearer <API_KEY>" \
-o invoice.pdf \
"https://api.example.test/v1/messages/msg_01hv3g9b3y4q4p9a6c/attachments/att_01hv3g9c"Mandrill Inbound Webhook Handler
// Node.js Express - parse mandrill_events and verify signature
import crypto from "crypto";
import express from "express";
import qs from "qs";
const app = express();
app.use(express.urlencoded({ extended: true }));
function verifyMandrillSignature(req, url, key) {
const signature = req.headers["x-mandrill-signature"];
// Build the signed payload: url + concatenated sorted POST params
const params = qs.parse(req.rawBody?.toString() || "");
const sorted = Object.keys(params).sort().map(k => k + params[k]).join("");
const signed = url + sorted;
const hmac = crypto.createHmac("sha1", key).update(signed).digest("base64");
return hmac === signature;
}
app.post("/mandrill-inbound", (req, res) => {
const events = JSON.parse(req.body.mandrill_events || "[]");
for (const ev of events) {
if (ev.event === "inbound") {
const msg = ev.msg;
// msg.text, msg.html, msg.attachments, msg.raw_msg (optional)
handleInbound(msg);
}
}
res.status(200).send("ok");
});
app.listen(3000);Note that Mandrill posts application/x-www-form-urlencoded, not JSON, so your server must parse form-encoded input and then decode the JSON array contained in mandrill_events. If you verify signatures, be sure to reconstruct the canonical string exactly as described in Mandrill's docs using your webhook key and the full URL.
Performance and Reliability Considerations
Throughput and Backpressure
- Webhook buffering: The platform queues deliveries and retries on non-2xx responses. You can temporarily absorb outages and replay later using REST.
- Mandrill Inbound: Retries on failure. If your endpoint cannot scale, you must provide your own queue or rate limit logic in front of your webhook.
Idempotency and Deduplication
- Deterministic message identifiers simplify dedupe. When the webhook retries, you can perform upserts keyed by
message_id. - Mandrill events arrive as an array with timestamps. Consumers often implement a content or header hash to avoid duplicate processing.
MIME Edge Cases
- Character sets: Non-UTF-8 charsets should be normalized with the original preserved in metadata to avoid data loss.
- Nested multiparts: Replies from mobile clients often include nested multipart/alternative inside multipart/mixed. Your parser must respect boundaries, otherwise inline images become attachments or are lost.
- Winmail.dat: Outlook's TNEF can hide the true attachment names. A platform can attempt extraction when safe, or forward winmail.dat as-is with clear metadata so you can decide.
- Long inline threads: Trimming quoted replies is an application concern. Your email parsing api should surface both raw and normalized bodies so you can choose.
Security and Authenticity
- HMAC webhook signatures are a must. Both platforms provide signatures. Validate on every request.
- Spam and authenticity signals like SPF, DKIM, DMARC should be included in the payload so you can route, quarantine, or tag messages appropriately.
Resilience Strategies
- Use a message store keyed by the platform's unique ID so you can replay without duplication.
- Keep raw MIME for at least a short retention window. You can re-parse with updated business logic without losing fidelity.
- Process attachments in a streaming fashion where possible to avoid memory spikes in your webhook handler.
- Separate immediate acknowledgement from downstream processing. Queue the work and return 200 quickly to keep retry counts low.
Planning a production-grade inbound pipeline touches broader email ops too. For a practical checklist approach, see Email Infrastructure Checklist for SaaS Platforms and explore ideas in Top Inbound Email Processing Ideas for SaaS Platforms.
Verdict: Which Is Better for Email Parsing API?
If you need a standalone, developer-first email parsing api with both webhook and REST polling, plus built-in controls for replay, artifact downloads, and idempotency, MailParse is the more flexible choice. It focuses on structured JSON output, MIME fidelity, and operational ergonomics that fit directly into modern service architectures.
If your organization already uses Mailchimp and wants a webhook-only inbound path that stays within that ecosystem, Mandrill Inbound is a reasonable option. You will build your own recovery and replay story around it, and you will parse the form-encoded event payloads into your internal representation.
For teams that prioritize fast integration, predictable payloads, and resilience under load, MailParse typically shortens build time and reduces operational toil. If you are optimizing within a Mailchimp-centric stack, Mandrill Inbound keeps everything under one vendor with a simpler account footprint. Your choice should track your operational requirements, not just brand familiarity.
Still estimating what it takes to ship inbound email features at scale? Check the tactical guide in Email Deliverability Checklist for SaaS Platforms and consider patterns from Top Email Parsing API Ideas for SaaS Platforms.
FAQ
Can I get raw MIME along with structured JSON?
Yes. A strong email parsing api should expose raw MIME as a first-class artifact. One option provides a REST endpoint to download the original message, while Mandrill Inbound includes raw_msg in the webhook when enabled. Keeping the raw source helps with audits, reprocessing, and edge case debugging.
How do retries and acknowledgements work?
Webhook handlers should return HTTP 200 as soon as the event is safely enqueued. Non-2xx responses cause retries in both systems, with exponential backoff. For fine-grained control, look for an ack endpoint or a replay mechanism so you can recover gracefully after an outage without double processing.
What about large attachments and streaming?
Platforms vary. Some include attachments as base64 blobs inside the webhook payload, which can bloat memory usage. Others provide lightweight metadata in the webhook and a REST download endpoint. For large files, prefer streaming downloads from a dedicated endpoint to keep your webhook fast and stable.
Does Mandrill Inbound require Mailchimp?
Yes. Mandrill Inbound is part of Mailchimp's transactional offering. You must configure inbound domains and routes within that account, which is fine if you are already standardized on Mailchimp but can be limiting if you want a standalone inbound service.
How do I verify webhook authenticity?
Both services provide HMAC signatures. Validate the signature on every request using your secret key. With Mandrill Inbound, reconstruct the canonical string using the request URL and sorted form parameters, then compare to the X-Mandrill-Signature header. With other providers, verify an HMAC of the raw JSON body against an X-Signature header using SHA-256.