Inbound Email API Pricing: CloudMailin vs SendGrid

Inbound email APIs look cheap when you compare the sticker prices, and most comparison posts stop there. The number that actually decides your bill is not the monthly plan. It is whether the provider hands you the data you wanted or a clean copy of the email that still contains it.

This is a pricing comparison of the three inbound providers US teams shortlist most often, with the figures pulled from each vendor in August 2026, plus the cost line none of them put on the pricing page.

What you are actually paying for

Every service in this category does the same core job. You route an email address or an MX record to the provider. Their servers accept the message, read the MIME structure, separate the plain text part from the HTML part, pull the attachments out, normalize a pile of character encodings into UTF-8, and then POST the result to a URL in your application.

That is genuinely valuable work. Writing a robust MIME parser is a miserable project, and running a mail server that accepts internet email without becoming a spam relay is worse. Paying $25 a month to never think about it again is a good trade.

What you are not paying for is field extraction. The payload you receive contains the whole email. If the thing you needed was the purchase order number, the ship date, and four line items, those are still sitting in a block of HTML inside that payload, and finding them is a job for code you write. None of the three providers below does this, and none of them claims to.

Inbound email API pricing compared

Figures checked on cloudmailin.com, postmarkapp.com and the Twilio SendGrid Inbound Parse documentation in August 2026. Vendor pricing changes, so confirm before you budget.

How much does CloudMailin cost?

CloudMailin lists a free plan at 10,000 emails a month with a 512KB per message limit, then Starter at $25 a month for 10,000 emails at 2MB, Professional at $45 for 20,000 at 10MB, and Premium at $85 for 40,000 at 50MB. Corporate plans run from $200 to $1,799 a month, covering 100,000 to 7 million messages. Paid plans advertise a seven day trial.

The tier ladder is worth reading carefully, because the thing that moves you up it is usually not volume. It is message size. A free plan that stops at 512KB per message is fine for reply-by-email and support threads and will start rejecting the moment somebody attaches a scanned invoice.

Is SendGrid Inbound Parse free?

Inbound Parse is not sold as a separate product. It is a feature you configure inside a SendGrid account by pointing an MX record at their servers, so the cost you carry is your SendGrid plan rather than a per-inbound-message rate. The documented limit is a 30MB total message size including attachments. If you already send transactional mail through SendGrid, inbound is effectively already paid for.

One documented gotcha is worth knowing before you build against it. If you choose the raw MIME option, SendGrid URL encodes the message but not the attachments, and code that only reads URL encoded content can silently drop them.

Does Postmark support inbound email?

Yes, but not on every plan. Postmark lists inbound email processing on its Pro plan at $16.50 a month and its Platform plan at $18 a month, both starting from 10,000 emails. The Free plan at 100 emails a month and the Basic plan at $15 do not include inbound. So the honest headline is that Postmark inbound starts at $16.50, and the $15 Basic plan that looks close is the wrong one.

What is the cheapest inbound email API?

On raw price, CloudMailin, because 10,000 messages a month on a free tier is more than the others include at any price. If you already pay SendGrid or Postmark for outbound mail, adding inbound there is cheaper still, since the marginal cost is zero or a few dollars. The cheapest option is almost always the provider you are already billed by.

What is an inbound parse webhook?

An inbound parse webhook is a service that receives email on your behalf and forwards it to a URL in your application as an HTTP POST. You point an address or MX record at the provider instead of running a mail server, and you receive a structured payload with the sender, subject, body, and attachments already separated. The parsing referred to is MIME parsing, not extracting business values.

The line item that is not on any pricing page

Here is where the comparison usually goes wrong. Three teams shortlist these vendors, argue about $25 against $16.50, and pick one. Six months later the bill for that decision is not the plan. It is the parsing layer they built behind the webhook.

The pattern is consistent. Somebody writes extraction code against the first vendor format they tested. A second supplier onboards with a different template, so a branch gets added. A third arrives and the function grows a switch statement. Then one supplier restyles their confirmation email, the regular expression that found the total stops matching, and the field comes through empty for two weeks before anyone notices, because empty is not an error. Nothing alerts. The rows just quietly go blank.

That endpoint also has to live somewhere. A webhook receiver is a small always-on service that has to stay reachable, get its certificate renewed, and be deployed and kept patched like any other production surface, because when it is down the provider retries for a while and then gives up on the message for good.

None of that appears on a pricing page. Priced honestly against a developer week, a parsing layer covering a handful of vendor formats costs more in its first month than three years of any plan in the table above.

When to buy delivery and when to buy extraction

The split is cleaner than the marketing suggests, and it comes down to what your application does with the message.

Buy an inbound email API when your product itself needs the email. Reply-by-email on comments and tickets, an application inbox, ingesting support requests, anything where the message is content your app stores and renders. You want the whole message, you have engineers, and volume is high. CloudMailin at 10,000 free messages a month is genuinely hard to beat here.

Buy an extraction tool when what you need is a handful of values from each message and the email itself is disposable. Purchase order numbers, invoice totals, ship dates, lead contact details, tracking numbers. The unit of value is the field, so paying per parsed email compares against manual data entry and parser upkeep rather than against a delivery rate. That is the trade a CloudMailin alternative built around named fields is making, and it only pays off at the volumes where extraction, not delivery, is the bottleneck.

Plenty of teams run both, and that is a reasonable architecture rather than a failure to choose. Application traffic goes through the inbound API to your own endpoint. The back office reporting, where somebody in finance wants a spreadsheet of totals and dates, goes through a parser that writes email data straight to Excel without an engineering ticket.

How to run the comparison on your own numbers

Take the last full month of the mailbox in question and count three things. First, how many messages arrived, which sets your tier. Second, the largest message including attachments, which is the number that actually decides your plan and the one most people forget. Third, and this is the one that matters, how many distinct sender formats you would need to handle, because that is the multiplier on the code you write.

If that third number is one and stable, write the parser and use the cheapest delivery tier you qualify for. If it is five and growing, the delivery price is noise. Compare the extraction tool against the engineering time instead, and if you want the head to head on that side, the SendGrid Inbound Parse alternative and Mailgun email parser alternative comparisons cover the same ground for those two providers. For the developer route where you want structured JSON without running the mail infrastructure yourself, the email parser API is the shorter path.

One honest limit on all of them

No service in this article, ours included, reads the inside of a PDF or Word attachment. Inbound APIs hand you the attachment as a file. Extraction tools like ours read the email body and any HTML tables in it. If the number you need is printed inside an attached document, that is document parsing, a separate category priced per page, and comparing inbound email pricing will not get you there. Worth checking before you sign anything, because it is the single most common reason a shortlist turns out to have been the wrong shortlist.