Email API Pricing: How to Compare Costs, Limits, and Deliverability

Email API pricing looks simple until you compare what each provider counts as an email, what is included in the plan, and which deliverability or operational features cost extra. The right choice is not necessarily the provider with the lowest advertised cost per thousand messages—it is the one whose billing model, limits, and tooling match how your application actually sends.

What email API pricing covers

An email API lets an application send messages programmatically through an HTTPS API or SMTP relay. Typical uses include password resets, login codes, receipts, order updates, invoices, account alerts, product notifications, and sometimes newsletters or lifecycle campaigns.

Most vendors charge for the number of messages sent in a billing period. But the price on a landing page may cover only the sending allowance, not every part of operating a reliable email program. The total can also depend on retention, inbound email processing, address validation, dedicated IPs, attachment size, support, analytics, or a separate marketing-email product.

Start by separating your workload into three categories:

1. Transactional email: one-to-one messages triggered by a user or system action, such as a receipt or password reset.
2. Bulk or marketing email: newsletters, product announcements, promotions, and lifecycle broadcasts sent to many subscribers.
3. Operational email infrastructure: authentication, event webhooks, suppression handling, logs, inbound routing, testing, and deliverability monitoring.

A provider may support all three, but it may not price all three together. Twilio SendGrid, for example, distinguishes Email API plans from its Marketing Campaigns offering. Postmark separates transactional and broadcast traffic through message streams, and its Bulk API requires account approval. (help.twilio.com)

The four email API pricing models

1. Pure pay-as-you-go pricing

With a usage-based model, you pay for each thousand emails or recipients with little or no fixed monthly commitment. This can be attractive if your volume varies substantially from month to month or if you send at very large scale.

Amazon SES is an example of a metered model. Its published Essentials outbound rate is $0.16 per 1,000 emails for the first 10 million emails per month, with lower marginal rates in higher usage bands. AWS says those bands are marginal: only the usage within each band receives that band’s rate. (aws.amazon.com)

The key word is marginal. If a provider lists one rate up to a threshold and a lower rate after it, do not multiply your entire volume by the cheapest rate. Price each portion of usage in its applicable tier.

2. Monthly plans with an included allowance

Many developer-focused email platforms charge a base subscription that includes a number of emails, then bill an overage rate for additional volume. This model makes a baseline budget predictable, but it can be inefficient if your actual volume is consistently far below the included allowance.

For example, Resend publishes plans beginning with a free tier of 3,000 emails per month, limited to 100 per day. Its published paid tiers include $20 for 50,000 emails, $35 for 100,000, and higher Scale tiers; overages vary by plan. (resend.com)

Mailgun similarly publishes a Basic plan beginning at $15 per month with 10,000 included emails, a Foundation plan at $35 with 50,000 included emails, and a Scale plan at $90 with 100,000 included emails. Its listed overage rates decline at larger tiers. (mailgun.com)

3. Volume bands with feature tiers

Some services combine volume pricing with a feature package. Moving to a higher plan is not just about more sends; it may unlock additional domains, longer activity-log retention, inbound processing, dedicated IPs, support channels, SSO, or team controls.

Postmark’s pricing illustrates this distinction. Its entry paid plans start at 10,000 emails per month, but the Basic, Pro, and Platform plans differ in the number of sending domains, retention options, inbound email processing, user limits, and overage rates. (postmarkapp.com)

This means two plans with similar sending capacity can have very different total value. If your incident-response process depends on message history, for example, short log retention can impose a real operational cost even if the sending bill is low.

4. Quote-based enterprise pricing

At enough volume or complexity, providers move to custom pricing. The quote may combine email volume with dedicated infrastructure, support commitments, data-retention requirements, security controls, regional routing, or deliverability services.

Custom pricing is not automatically expensive or bad. It is usually appropriate when you need a contractual SLA, dedicated IP pools, SSO, extensive subaccount management, a large number of sending domains, or unusually high throughput. It does mean you should model the proposal carefully: request a rate card for overages, included services, renewal terms, implementation work, and any minimum commitment.

How providers count an “email”

Never assume that one API call equals one billable email. A message sent to three recipients can be treated as three sends, and different providers define quotas differently.

Amazon SES explicitly states that its sending quotas are based on the number of recipients rather than the number of messages. A single message addressed to multiple recipients therefore consumes multiple units of sending capacity. (docs.aws.amazon.com)

This matters for cost forecasting. If your product sends a monthly invoice to one billing contact, your message count and recipient count are nearly identical. If your application sends notifications to a five-person team, a single business event may produce five billable deliveries.

Use this planning formula:

monthly billable sends =
  transactional recipients
+ marketing recipients
+ retries or duplicate sends
+ test and staging sends
+ internal copies, if sent through the provider

Do not count only production API calls. Add test traffic, support re-sends, backfill jobs, and automated retry behavior. If a job retries after a timeout without idempotency protection, it can create both duplicate email and duplicate billing.

Resend supports an Idempotency-Key header for its single-email and batch endpoints. It checks whether the same key was already used within the previous 24 hours, which allows a client to retry safely without sending a duplicate message. (resend.com)

The costs that are easy to miss

The headline send rate is only one line item. Before comparing providers, make a list of features your team will actually use and determine whether they are included, capped, or sold separately.

Overage charges

An overage is the price for messages above your plan’s included volume. Providers can charge it per thousand emails, use a higher-volume plan automatically or manually, or require a custom agreement after a certain threshold.

A low base plan with high overages can be more expensive than a larger plan. Conversely, buying a very large allowance “just in case” can waste money if your volume is seasonal.

For example, Mailgun lists overages from $1.80 per 1,000 on Basic, $1.30 per 1,000 on Foundation, and $1.10 per 1,000 on Scale. Resend lists plan-dependent overages, including $0.90 per 1,000 on its published 50,000- and 100,000-email Pro tiers. (mailgun.com)

Attachments and data transfer

Attachments are a cost and deliverability decision, not merely a template feature. Some providers apply data charges in addition to message charges. Amazon SES lists an additional $0.12 per GB for attachments sent, and notes that other data-transfer charges may apply in some AWS usage patterns. (aws.amazon.com)

For invoices, exports, and reports, consider storing the file in your application and sending an authenticated download link instead. This reduces message size, simplifies retries, and gives you better control over access expiration.

Email validation

Validation products can be useful for reducing obvious invalid-address sends, but they are frequently priced separately from delivery. Mailgun lists validation add-ons or included validation quotas depending on the plan, while Amazon SES lists API validation as an add-on or plan inclusion depending on the subscription tier. (mailgun.com)

Validation is not a replacement for handling hard bounces and suppressions. Treat it as one layer in a quality process: validate appropriate imported addresses, suppress permanent failures, and do not repeatedly send to addresses that have bounced. For one-off checks before a manual import, use an email address verification tool rather than treating your transactional provider as a list-cleaning service.

Dedicated IPs and deliverability services

Shared IP sending is common and often suitable for new or modest-volume products. Dedicated IPs can be useful for organizations with sufficient consistent volume and mature deliverability operations, but they add cost and require reputation management. A dedicated IP does not repair poor list practices, weak authentication, or unwanted mail.

Plan differences can be significant. Mailgun’s Scale tier includes dedicated IP pools, while its Foundation tier provides access to a dedicated IP at 50,000-email volume and its Scale tier includes an IP. Twilio SendGrid says dedicated IPs are included in Pro and Premier plans. (mailgun.com)

Retention, observability, and support

When an important email fails, your team needs to answer basic questions: Was it accepted? Was it delivered? Did it bounce? Which template and event triggered it? Is the address suppressed? How long can you investigate after the fact?

Those answers depend on event webhooks, logs, and retention. Postmark lists 45-day default message retention, with longer customized retention available on eligible plans. Mailgun lists one day of log retention on Free and Basic, five days on Foundation, and 30 days on Scale. (postmarkapp.com)

If your support team investigates issues weeks later, a cheaper plan with one day of logs may be a false economy. Export events to your own data store if provider retention does not meet your operational or compliance needs.

Email API pricing comparison: what the published plans reveal

The following comparison is a way to understand pricing structure, not a promise that every plan will remain unchanged. Confirm the provider’s current checkout page and contract terms before buying.

The figures in this table come from the vendors’ published pricing pages. (aws.amazon.com)

A simple rule of thumb follows:

• Choose metered pricing when volume is high, volatile, and your team can operate the platform’s surrounding infrastructure.
• Choose an allowance-based developer platform when predictable pricing, SDKs, templates, and a simpler workflow matter more than the absolute lowest unit price.
• Choose a feature-tier provider when retention, inbound routing, user roles, support, or separation of transactional and bulk mail are essential.
• Choose an enterprise agreement when your technical and compliance requirements are the main buying criteria.

If you are comparing a managed platform against an in-house AWS implementation, include engineering time, alerting, DNS management, event ingestion, template tooling, and on-call support—not just per-message spend. The same principle applies when evaluating transactional email pricing: compare the total operating fit, not a single unit rate.

Worked example: price a SaaS application sending 75,000 emails per month

Assume a B2B SaaS application sends the following average monthly volume:

• 35,000 login or security-code emails
• 20,000 product notifications
• 15,000 receipts and invoices
• 5,000 support-triggered re-sends and test messages

That is 75,000 billable deliveries per month, assuming one recipient per message and no attachments. The company needs webhooks for delivery and bounce events, a verified domain, and enough history for support investigations. It does not need a dedicated IP yet.

Step 1: Calculate the send-only baseline

For Amazon SES Essentials, the published first-tier price is $0.16 per 1,000 emails.

75,000 / 1,000 × $0.16 = $12.00 per month

That calculation covers the published outbound sending rate only. It does not include any optional AWS services, attachment data, validation, deliverability add-ons, or engineering work involved in building surrounding operations. (aws.amazon.com)

For Resend, the published $35 Pro plan includes 100,000 emails per month. At 75,000 emails, the workload falls within that included allowance, subject to the plan’s current terms. (resend.com)

For Mailgun, the published Foundation plan is $35 for 50,000 included emails and lists $1.30 per additional 1,000 emails. The estimated send charge at 75,000 is:

$35.00 base
+ (25,000 / 1,000 × $1.30) overage
= $67.50 per month

That estimate assumes the Foundation plan, current published overage, and no validation, dedicated IP, or additional product charges. (mailgun.com)

For Twilio SendGrid, the published Essentials plan starts at $19.95 and is presented for a 50,000-to-100,000 monthly-email range. Treat the vendor’s checkout configuration, available features, taxes, and any stated overages as the final source of truth for the exact total. (twilio.com)

Step 2: Add operational requirements

Now ask questions that a send-only comparison misses:

• How many days of message and event history does support need?
• Does the application need inbound email parsing for replies or tickets?
• Are templates managed in code, in the provider dashboard, or both?
• Will the business want a separate marketing stream and unsubscribe workflow?
• Does the team need SSO, multiple users, or subaccounts?
• Is address validation necessary for imported contacts, and how many checks will occur monthly?

A provider that costs more per send may be cheaper overall if it includes the logs, inbound processing, team controls, and support workflow you would otherwise build or buy separately.

Step 3: Choose a budget guardrail

Set a volume alert below the next commercial threshold. For this example, alert at 80,000 emails and investigate at 90,000. The goal is not merely to control spend: a sudden volume jump can signal an application loop, abuse, a malfunctioning retry queue, or an unexpected campaign.

Also create a daily cap or anomaly alert for sensitive message types. Password-reset email volume that unexpectedly triples is a security event before it is a billing event.

How to avoid common email API pricing mistakes

Mistake 1: Choosing by the lowest cost per 1,000

A low unit rate is meaningful, but not sufficient. A provider with a cheap sending rate can still cost more after you add validation, logs, deliverability monitoring, dedicated IPs, or engineering time.

Fix it by using two columns in your model: provider invoice and internal operating cost. Include the time required to maintain webhooks, templates, suppression logic, dashboards, and incident response.

Mistake 2: Ignoring free-tier production limits

Free plans are excellent for integration testing and early prototypes. They are often unsuitable for a production notification system because of daily caps, domain restrictions, limited retention, or no overages.

Resend’s free plan has a 3,000-email monthly allowance and a 100-email daily limit. Mailgun’s free offering includes 100 emails per day, while Postmark’s free Developer tier includes 100 emails per month with no overages. (resend.com)

Model peak-day traffic, not just average monthly traffic. A product that sends 2,000 password resets during an outage needs a provider and account configuration that can accept the burst.

Mistake 3: Treating retries as free

Network failures happen. If your application times out after submitting a send request, the provider may have accepted the message even though your application did not receive the response.

Use idempotency keys where your provider supports them, persist message intent before sending, and record the provider message ID. Resend keeps idempotency keys for 24 hours; Postmark returns a MessageID in its sending workflow, which you can store for traceability. (resend.com)

Mistake 4: Using one stream and domain for every kind of email

Password resets, receipts, newsletters, and cold outreach do not have the same recipient expectations or reputation risk. Keep transactional and promotional traffic logically separated, and follow your provider’s product rules for each category.

Postmark supports transactional and marketing/broadcast message streams, and its documentation specifically directs broadcast campaigns to its Bulk API rather than the transactional batch endpoint. (postmarkapp.com)

Mistake 5: Underestimating deliverability requirements

A paid API account does not guarantee inbox placement. Providers can accept a message and report delivery to the receiving mail server, but only recipient engagement and mailbox-provider filtering determine whether a message is visible in the inbox, spam folder, or another tab.

Google requires all senders to set up SPF or DKIM. Senders that send more than 5,000 messages per day to Gmail accounts must use SPF, DKIM, and DMARC, and must satisfy additional requirements such as valid forward and reverse DNS and TLS. (support.google.com)

Setup checklist: make the price comparison real

Before committing to a provider, run this short implementation exercise in a staging environment.

1. Verify a sending domain. Prefer domain-level verification rather than verifying a single mailbox. Amazon SES notes that verifying a domain lets you send from addresses and subdomains under that verified domain, while an address identity limits sending to that address. (docs.aws.amazon.com)
2. Publish authentication records. Follow the exact SPF and DKIM values generated by your provider. Add a DMARC record, beginning with monitoring if your team has not yet reviewed all legitimate senders.
3. Use a valid From address. For example, Acme Alerts <notifications@example.com> is clearer than an unbranded provider domain.
4. Create a restricted production API key. Store it in a secrets manager; never expose it in browser code, a mobile app, or a public repository.
5. Send one test message with HTML and plain text. Check the provider dashboard for acceptance and the destination mailbox for authentication results.
6. Configure event webhooks. Ingest delivered, bounced, complained, delayed, and unsubscribed events into your application or analytics system.
7. Implement suppression logic. Stop retrying hard bounces and honor unsubscribes for messages that are promotional.
8. Set cost and volume alerts. Trigger alerts before a plan boundary or quota limit, not after.
9. Test failure behavior. Simulate a timeout and confirm your idempotency logic does not create duplicate email.
10. Document the exit path. Keep templates, recipient data, and event history portable enough to change providers if requirements change.

A generic DMARC monitoring record has this form:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Use p=none only as a monitoring starting point if it fits your organization’s policy. Review reports, identify every legitimate sending service, and then decide whether a stricter enforcement policy is appropriate. Do not copy an SPF or DKIM value from a generic example: those values must come from the email provider you are authorizing.

How to tell your email API setup is working

A successful API response is necessary but not enough. Verify the full chain from request to recipient and from recipient event back to your application.

Your setup is working when all of the following are true:

• Your provider accepts the message and returns a provider message ID.
• The recipient receives the intended message without duplicate copies.
• The message headers show passing authentication appropriate to your configuration.
• Delivery, bounce, complaint, and unsubscribe events reach your webhook endpoint.
• Your application stores the event and associates it with the relevant user, order, or notification.
• A deliberate bad address produces a bounce or rejection that your suppression workflow handles.
• A retry of the same logical notification does not result in a second message.
• Your dashboard and internal metrics agree closely on sent volume.

For an API-level smoke test, keep the request small and deterministic. Use a stable test recipient, an identifiable subject such as Email API integration check, and a unique application event ID. Then inspect both the inbox and the provider event timeline.

Postmark offers a test token, POSTMARK_API_TEST, that validates request data without delivering the message. Its batch endpoint supports up to 500 messages per API call and a 50 MB payload including attachments. Resend’s batch endpoint supports up to 100 emails per request. These limits are implementation details, not billing rules, but they matter when you design queue workers and backfill jobs. (postmarkapp.com)

When the cheapest provider is the wrong choice

The cheapest provider is often the right choice for a technically experienced team sending straightforward, high-volume transactional email. It can be the wrong choice when the business lacks the time or expertise to operate surrounding deliverability and observability systems.

Choose a more managed service when you need fast implementation, strong template tooling, visible activity history, easier event handling, responsive support, or a clearer operational interface for non-engineering teammates. Choose a lower-level metered service when your volume is large enough for the savings to outweigh the additional engineering responsibility.

Also distinguish price sensitivity from risk sensitivity. A $20 monthly difference is not meaningful if a missed password reset, duplicate invoice, or uninvestigated delivery failure costs substantially more in customer trust and support time.

Conclusion

The best email API pricing decision begins with a workload model, not a provider comparison table. Count recipients rather than just API calls, forecast peaks rather than averages, include overages and add-ons, and assign a cost to the operational features your team would otherwise build.

For a small application, a free plan or simple monthly allowance can be the fastest safe starting point. For a growing SaaS product, the right plan usually balances included volume, reliable event webhooks, usable retention, and predictable overages. For high-volume teams, metered pricing can be compelling—but only when authentication, suppression handling, quota management, and monitoring are part of the implementation plan.

FAQ

How much does an email API cost?

Email API cost ranges from free development tiers to usage-based pricing measured per thousand emails, monthly plans with included allowances, and custom enterprise contracts. Published examples include Amazon SES Essentials at $0.16 per 1,000 outbound emails in its first tier, Resend paid plans from $20 per month, Mailgun from $15 per month, Postmark from $15 per month, and Twilio SendGrid Essentials from $19.95 per month. (aws.amazon.com)

Is email API pricing based on emails or recipients?

It depends on the provider. Amazon SES explicitly bases its sending quotas on recipients, not messages. Check the billing documentation for your selected service, especially if your application commonly sends a single message to multiple recipients. (docs.aws.amazon.com)

Are transactional emails cheaper than marketing emails?

Not necessarily. Transactional email is often priced by messages sent, while marketing products may price by sends, contacts, automation features, or a separate plan. The meaningful comparison is the workload and feature set, not the label on the email type.

Do I need a dedicated IP for transactional email?

Usually not at the beginning. Dedicated IPs add cost and operational responsibility. Consider them only when you have consistent enough volume and a clear reason to manage a separate sending reputation; shared infrastructure is often appropriate for new or lower-volume transactional senders.

What should I budget beyond sending volume?

Budget for overages, attachment data, validation, message retention, deliverability tools, dedicated IPs, support, taxes, and engineering time for webhooks, suppression handling, dashboards, and incident response. Those items often determine the true cost of an email API.