Postmark Inbound alternative that extracts the fields for you

Postmark is very good at what it does. Its inbound processing receives mail for your domain or for a unique address on its own inbound hostname, parses the MIME, and posts one JSON document per message to your webhook. You get From, To, Cc, Subject, Date, TextBody, HtmlBody, all headers, and an Attachments array where each file is base64 in a Content field. Two extras help with replies: StrippedTextReply drops the quoted history from replies, and MailboxHash carries the tag from an address such as [email protected].

What Postmark does not do is read the message for meaning. If the email is a purchase order, a dealer lead or a carrier update, the PO number, the line items and the delivery date are still somewhere inside TextBody, HtmlBody or a PDF, and your code has to find them. That code is where the real cost lives: regex per sender, an HTML table walker, a PDF library, and a fix every time a supplier changes its template.

ParsedMail starts where Postmark stops. You describe the fields once, in plain English, and every email to the inbox produces a JSON object with those fields, typed and normalized (dates in ISO 8601, amounts as numbers), each with a confidence score between 0 and 1. The example above shows a lead email going in and the finished record coming out.

Facts about Postmark come from its pricing page and its inbound developer guide, checked in October 2026.

Read the price row carefully. Per message, Postmark is far cheaper, because it moves mail and leaves the work to you. ParsedMail charges for the extraction. The fair comparison is Postmark plus the parser you build and maintain, against ParsedMail alone.

Keep Postmark if your product needs the message, not values from it:

• Reply by email. Comment threads, help desk replies and chat by email, where you store what the person wrote. StrippedTextReply and MailboxHash were built for this, and they do it well.
• High volume, simple routing. Tens of thousands of messages a month where you only route on the recipient or subject. Paying for AI extraction you do not use makes no sense.
• One stable sender. If every email comes from your own system in a format you control, a small parser on top of Postmark JSON is cheap to keep alive.
• You already send through Postmark and want one vendor and one bill for both directions.

• The next system needs fields. A sales order in the ERP, a contact in the CRM, a row in a sheet, a payable in accounting. See purchase order emails to ERP and lead emails to CRM.
• Many senders and layouts. Fifty suppliers or six lead portals each format the same facts differently. One field description covers all of them, so a new sender does not mean a new parser.
• The data is in a PDF. Invoices, packing lists and rate confirmations usually travel as attachments. ParsedMail reads the attachment and the email text in the same pass, see attachments and PDF parsing.
• Wrong values cost money. A misread quantity ships the wrong order. Confidence scores let your handler post what is certain and hold the rest for a person in the review queue.

A Postmark Inbound handler usually reads TextBody or HtmlBody, decodes the base64 attachments, and then runs its own extraction per sender. With ParsedMail the handler checks a signature and reads values that are already there:

# Flask
@app.post("/hooks/parsedmail")
def parsedmail_hook():
    if not verify(request.headers["ParsedMail-Signature"], request.get_data(), WHSEC):
        abort(400)
    event = request.get_json()
    lead = event["data"]["data"]   # customer_name, phone, vehicle_of_interest, ...
    if event["data"]["needs_review"]:
        return "", 200             # a person approves it first
    crm.create_lead(lead, idempotency_key=request.headers["Idempotency-Key"])
    return "", 200

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

1. Pick one flow. Start with the one whose parser breaks most often, usually purchase orders or lead notifications. Leave reply by email on Postmark.
2. Create an inbox and describe the fields. Reuse the field names your current parser outputs, so downstream code keeps working without new mappings.
3. Replay a sample. Forward 20 real emails, including the odd ones, and compare the JSON with what your parser produced. Tighten any field description that scores below 0.8.
4. Run both for a week. Add a forwarding rule or a BCC so both receive live mail. Your Postmark webhook keeps doing the job while you watch ParsedMail results.
5. Cut over. Point the sender or the forward at the ParsedMail address, delete the extraction code for that flow, and keep Postmark for everything else.

No DNS change is needed. Every inbox has an address on in.parsedmail.com; on Scale you can receive on your own inbound domain instead.

A Postmark Pro plan at 10,000 emails is a small line on the bill. The parser behind it is not. Take a typical order intake flow with 30 senders: a developer spends a few hours a month on new layouts and broken regex, and every miss is an order someone keys in by hand or a customer who waits. At a loaded cost of $90 an hour, three hours a month is $270, before anyone counts the orders that went wrong.

ParsedMail Starter is $24 a month billed yearly for 1,000 emails, Growth is $74 a month for 5,000 emails with the review queue and 5 seats, and Scale is $249 a month for 25,000 emails with a custom inbound domain and SSO. See pricing for the full table. If your parser never breaks, stay where you are. If it is a standing ticket, the plan costs less than the ticket.