SendGrid Inbound Parse alternative that returns parsed JSON

SendGrid Inbound Parse is a mail receiver. You point the MX record of a hostname at SendGrid (priority 10, mx.sendgrid.net), and every message to that hostname is posted to your URL. By default the POST is multipart/form-data with parts such as headers, from, to, subject, text, html, envelope, attachment-info and one part per attachment. There is also a raw mode that sends the full MIME message in one email field. Either way, the email arrives as an email.

That is the right shape if your product is a mail client or a help desk. It is the wrong shape if what you need is the PO number, the ship-to address and the line items, because every team then writes the same code: decode the parts, strip quoted replies and signatures, read the PDF, find the values, and keep those rules alive when a sender changes its template.

ParsedMail does that second half. Each workflow gets an inbox address, you describe the fields in plain English, and your endpoint receives one signed POST per email with the values already extracted and typed. The example above is a real-shaped purchase order and the JSON your webhook would get. How the reading works is covered on the AI email parser page.

Facts about SendGrid come from its Inbound Parse documentation, checked in October 2026.

Keep SendGrid if you need the whole message and nothing else. Typical cases:

• You are building reply-by-email for comments or tickets, and you store the text and HTML as written.
• You archive messages for compliance and need every header and the original MIME.
• You already send through SendGrid, your volume is high, and your team owns a parser that works for a small set of fixed, machine-generated layouts.
• You need the SPF and DKIM results and the spam score that SendGrid adds to each POST.

In those cases a raw inbound pipe is cheaper and simpler, and adding a parsing layer on top would only add cost.

• The values matter, not the message. Purchase orders, supplier invoices, lead notifications, booking confirmations and carrier updates, where the next system needs fields. See purchase orders to ERP and lead emails to CRM.
• Many senders, many layouts. One schema covers every supplier, because the model reads meaning instead of positions. A new customer does not need a new regex.
• The data is in a PDF. Invoices and POs often live in the attachment, and ParsedMail reads it together with the body. Details on attachments and PDF parsing.
• Wrong values are expensive. Every field has a confidence score, missing values come back empty instead of guessed, and anything under your threshold can wait for a person in the review queue.
• No mail team. Nobody has to own MX records, MIME decoding and a parser for each sender.

A typical Inbound Parse handler reads the form parts, decodes charsets, finds the attachment files, and then runs its own extraction. After moving to ParsedMail the handler verifies a signature and reads fields that are already there:

// Express, raw body for the signature check
app.post("/hooks/parsedmail", express.raw({ type: "application/json" }), (req, res) => {
  if (!verify(req.get("ParsedMail-Signature"), req.body, process.env.PARSEDMAIL_WHSEC)) {
    return res.sendStatus(400);
  }
  const event = JSON.parse(req.body);
  const po = event.data.data;          // { order_number, ship_to_address, line_items, ... }
  if (event.data.needs_review) return res.sendStatus(200); // a person checks it first
  queue.add("create-sales-order", po, { jobId: req.get("Idempotency-Key") });
  res.sendStatus(200);
});

The full signature check, in Node and Python, is on the inbound email webhook page, and every endpoint is listed in the email parsing API reference.

1. List your inbound flows. Usually one hostname per flow, such as orders, invoices or leads. Each becomes a ParsedMail inbox with its own address.
2. Describe the fields. Reuse the field names your current parser outputs, so the services downstream keep working without new mappings.
3. Replay a sample. POST 20 to 50 stored messages as raw MIME to /v1/inboxes/{id}/emails and compare the JSON with what your parser produced. The format is described in sending emails to the API.
4. Run both in parallel. Keep the SendGrid MX in place and forward or BCC a copy of the live mail to the new inbox address for a week.
5. Switch over. Point the senders, or your forwarding rule, at the ParsedMail address, then retire the old handler and the parsing code behind it.

If you only need to move one hostname and keep SendGrid for sending, nothing else changes on your outbound side.

The inbound pipe is rarely the expensive part. The expensive part is the extraction code behind it: rules per sender, PDF handling, edge cases, and the on-call ticket when a supplier redesigns its order confirmation. Count the engineering hours you spent on that code in the last quarter and compare them with a plan price.

ParsedMail Starter is $49 a month, or $24 a month billed yearly, for 1,000 emails and 300 attachment pages. Growth is $149 a month for 5,000 emails, 2,000 pages, 5 seats and the review queue. Scale is $499 a month for 25,000 emails, 10,000 pages, a custom inbound domain, SSO and an audit log. Every limit is on the pricing page.