7 Email Parsing Software Tools and APIs Compared (2026)

Every business has emails that arrive in the same shape over and over. Order confirmations, web form leads, supplier invoices and shipping notices all carry a few facts someone needs elsewhere. So a person copies the order number, the total and the customer name into a spreadsheet. That person gets bored fast.

Developers hit a different version of the same problem. An app or an AI agent that receives email gets a MIME file. MIME is the raw format of an email, with headers, body parts and encoded attachments stacked together. The code then has to find the one new sentence the sender typed above three replies of quoted history.

Both groups type the same phrase into a search box, and most of the lists they find only cover the first job. Below, the two kinds sit side by side with the seven tools worth a look. After that comes how each parsing method holds up when a layout changes, and the monthly bill at 1,000 emails.

What is email parsing software?

Email parsing software reads incoming email and hands back its contents in a form a program or a spreadsheet can use. It comes in two kinds.

A no-code parser pulls named fields out of emails that follow a pattern, such as an order number or a lead's phone number. It then sends a row to Google Sheets, a CRM or Zapier. An inbound email API receives mail for your domain and decodes the MIME. It sends the message to your server as an HTTP POST, with body, headers and attachments already separated.

Pick by the output you need. A row of data for a person to work with: Parseur, Mailparser or Email Parser by Zapier. A message your software reads and answers: Mailgun, Postmark, SendGrid Inbound Parse or AgentMail.

Between those two sits a step many teams forget. Someone has to strip the quoted history so only the sender's new words remain. That step is where the developer tools differ most.

7 email parsing tools compared

The table puts both kinds side by side, with what each one returns and the job it fits. The first three return data. The last four return messages.

That split decides more than any feature row. A field extractor cannot answer an email. An inbound API will not fill a spreadsheet until someone writes the code that does it.

Which no-code email parser fits recurring business emails?

No-code parsers fit when the same kind of email arrives every day and a person needs its fields somewhere else. All three work without code. Each makes a different bet on how to find the data.

Two extraction engines come with every Parseur plan, free tier included. The AI engine takes a name and a short description for each field, then finds it across layouts with no template. The template engine asks you to mark up each layout once and matches later documents against it. Exports to Excel, CSV, JSON, Google Sheets, Zapier, Make, Power Automate, webhooks and the API are on every tier.

Parseur bills by page. An email counts as one page however long it is. A three-page PDF attachment counts as three, so invoice-heavy inboxes burn credits faster than the email count suggests.

Rules you write per inbox are the core of Mailparser. You show it where a value sits in a sample email and how to cut it out. The same rules then run on every email that follows. That holds until the layout moves.

It reads csv, xlsx, docx, pdf and txt attachments, but not images or scanned documents. The Mailparser pricing FAQ sends OCR work to its separate Docparser product. When a paid plan runs out of credits, new emails wait in the parsing queue instead of being dropped.

A mailbox at a robot.zapier.com address is how Email Parser by Zapier starts. You forward a sample email, highlight the words you want, and label each one. Each label becomes a field in your Zap.

The Email Parser setup guide lists the limits: 15 templates, a mailbox address you cannot change, and several attachments delivered as one zip file. It also warns that forwarded emails with extra signatures break the pattern. Most real inboxes look like that.

Which inbound email API gives your code parsed JSON?

Inbound APIs receive the email for you and POST it to an endpoint you run. Pipes, with parsing. You skip the mail server and the MIME decoding, but storage, duplicate handling and the decision about what to say back all stay in your code.

Routes are how Mailgun receives. A route's forward() action POSTs a parsed copy of each message to your URL. The body-plain field is always present, and when the sender only wrote HTML, Mailgun tries to build a text version for it.

Mailgun also tries to fill stripped-text, the reply without quoted parts or the signature block. When that parsing fails, the stripped fields are absent. A destination URL ending in json gets one JSON document with attachments base64-encoded inside. Failed POSTs retry for 8 hours. A 406 response stops them.

Postmark sends one JSON webhook per inbound message. Each POST carries TextBody, HtmlBody, every header, base64 attachments and a StrippedTextReply field. That field holds the new reply alone. It is narrow by design, because it covers English text only, reads plain-text parts only, and is filled only when the message has an In-Reply-To or References header. Attachments may total 35 MB, and a failed POST gets 10 retries at intervals that grow from one minute to six hours.

DNS comes first with SendGrid Inbound Parse. You point the MX record of a dedicated subdomain at mx.sendgrid.net. SendGrid then POSTs each message as multipart form data with text, html, headers, SPF and DKIM results, and attachment details as JSON.

With the spam check on, messages of 2.5 MB or less also get a spam_score. There is no reply field. Your code separates the quoted history itself.

The Inbound Parse setup docs flag one trap. Without the raw MIME option, the message is URL-encoded but its attachments are not. Code that reads only the URL-encoded content drops the files.

Every one of these webhooks also needs a fast answer and a signature check. Postmark waits up to 2 minutes for your server to respond, and a 403 stops its retries. Mailgun signs each POST with an HMAC, and JSON payloads carry that signature in an X-Mailgun-Signature header. Verify it. Email content is untrusted input even when a provider parses it cleanly.

Reply parsing gets a longer treatment in the comparison of inbound reply parsers for agent inboxes. Before any of these webhooks takes real traffic, a checklist for testing inbound email webhooks catches the retry and payload bugs that only show up in production.

Do you still need a parser when the inbox returns clean fields?

Often you do not, because most code needs two things: the new reply and the text inside attachments. AgentMail is an inbox API. Each inbox is a real email address with its own stored messages and threads, created with one API call. Every stored message carries extracted_text and extracted_html next to the full text and html.

Extraction removes quoted history in English and many other languages, among them French, German, Chinese and Arabic. It also cuts "Sent from my iPhone" lines, unsubscribe footers and legal disclaimers. The sender's own signature stays.

Those fields come back on Get Message and on each message in Get Thread. They also ride on the message.received webhook and WebSocket events. List Messages returns metadata and a preview only. Events for very large messages leave body fields out to stay under size limits, so code falls back to Get Message when they are missing.

Attachments get the same treatment. Get Attachment returns a text_url next to the download_url for the original file. The text comes from a PDF's text layer, or from a Word, Excel, CSV, Markdown, JSON or HTML file. Files over 10 MB are skipped, and text stops at 250,000 characters. The extractor is open source as agentextract on npm, MIT licensed, so the same rules run on mail that never touches AgentMail.

This script reads one message with the Python SDK. It prints the new reply, then fetches the text of each attachment.

# Read the new reply and attachment text from one message (agentmail 2.0.17)import osimport httpxfrom agentmail import AgentMailclient = AgentMail(api_key=os.environ["AGENTMAIL_API_KEY"])inbox_id = "orders@northwind-supply.com"message = client.inboxes.messages.get(    inbox_id=inbox_id,    message_id="<CAF3x9Lq2mP7@mail.gmail.com>",)print(message.extracted_text or message.text)for item in message.attachments or []:    attachment = client.inboxes.messages.get_attachment(        inbox_id=inbox_id,        message_id=message.message_id,        attachment_id=item.attachment_id,    )    if attachment.text_url:        text = httpx.get(attachment.text_url).text        print(item.filename, "->", text[:43])    else:        print(item.filename, "-> no text, use download_url")# Output:# Confirmed, PO 4471 attached. Ship to the Austin warehouse.# PO-4471.pdf -> Purchase Order 4471 Northwind Supply Net 30# pallet-photo.jpg -> no text, use download_url

The reply came back without the quoted order email below it. The PDF came back as text with no document parser. What did not come back is a field called po_number.

Turning "PO 4471, ship to Austin" into a record is still a job for your code or a model. The difference is that the model now reads two short strings instead of a MIME file. The reply and attachment extraction docs list every supported format. For the receive side end to end, see building real-time agents on AgentMail webhooks.

Rule-based, template or AI parsing: which holds up when layouts change?

AI field extraction survives layout changes best. Rules stay the most predictable while the layout holds, and templates sit between the two, trading some setup work for some tolerance of change. The method matters more than the vendor.

Rules are what Mailparser runs. Reply strippers such as AgentMail's extraction are rule-based too. The same input gives the same output every time, and you can read why a value came out wrong. Rules break when a sender redesigns the email, and they break quietly, because a rule that finds nothing returns an empty field instead of an error.

Templates are what Email Parser by Zapier and Parseur's template engine use. You mark up an example, and the tool matches later emails to it. Parseur keeps several templates per mailbox and picks the best fit for each document. Zapier stops at 15.

AI fields are Parseur's AI engine. You describe the field in words, and the engine finds it across layouts. The tradeoff is control. When it misreads a value, there is no rule to fix, only a description to reword.

Suppose a supplier adds a logo row above its invoice table. With rules, the total column goes blank until someone edits the rule. With templates, someone builds a template for the new layout. With AI fields, nothing changes as long as the description still fits.

Keep the original body whichever method you pick. Mailgun calls its stripped fields best effort. Postmark says it makes a best attempt. AgentMail's docs note that an unusual layout can leave quoted text in. Read the clean field first, and fall back to the full body when it is missing.

What does email parsing cost at 1,000 emails a month?

At 1,000 emails a month, Parseur and Mailparser cost $84 to $129. The developer tools start between $0 and $16.50. Each row is the entry plan on the vendor's own pricing page that fits that volume. Where a vendor bills by something other than emails, the row shows its closest public price.

No-code prices cover the whole job, from mailbox to spreadsheet row. Parseur's unused credits expire at the end of each billing period. At 100 percent usage, new documents stop processing until you upgrade or the plan renews. Mailparser's yearly plans hand over the full year of credits on day one, so a busy month can borrow from a quiet one.

Developer prices cover receiving and parsing only. Storage, duplicate handling on your endpoint, and reply stripping where the payload has none are code your team writes and runs. AgentMail's Free plan covers 1,000 emails a month with room to spare. The Developer plan is $20 a month for 10 inboxes and 10,000 emails, for when one agent becomes ten.

What AgentMail does not do

AgentMail does not pull named fields such as an invoice number into a schema, and it does not push rows to a spreadsheet or a CRM. Your code or a model does that step. It has no OCR, so scanned PDFs and images return no text_url, and forwarded emails can lose the forwarded part in extracted_text. A team that wants rows without writing any code needs a no-code parser instead.

Choosing by the output you need

Parseur fits business emails whose layouts change without warning. Mailparser fits one or two stable formats at a steady volume. Email Parser by Zapier fits a single email type that feeds a Zap.

Mailgun fits teams that already send through it. Postmark fits apps that want the English reply back as one field. SendGrid Inbound Parse fits teams that want spam scores and SPF results in the POST. AgentMail fits agents and apps that read a reply and answer it in the same thread.

More comparisons like this one are on the AgentMail blog.