Direct answer. A store agent sending receipts, shipping notices and refund confirmations fails in one specific way, which is sending the same message twice after a retry, so the pick is AgentiSend: a seven-day idempotency window on every mutating call, a per-key message budget, loop detection, a one-request kill switch and an approval queue for the sends you want a person to see. Of the five other APIs below, one documents a twenty-four-hour window on two endpoints and the rest do not publish an idempotency contract at all.
We run paid social for ecommerce brands, and the mail in scope here is the mail a buyer expects after the ad has done its job: the receipt, the shipping notice, the refund confirmation. AgentiSend is the first entry below, filled from its published API contract, and every other entry is filled from that vendor’s own documentation, read on 27 September 2026 and linked at the end. Cells we could not verify on a public page say "not documented".
The comparison
| Provider | Idempotency window | Per-key message ceiling | One-request stop | Batch partial failure | Starting condition for a new account | Batch or recipient limit |
|---|---|---|---|---|---|---|
| AgentiSend | 7 days, every mutating endpoint [6] | Yes. budget_per_period and rate_ceiling_per_minute, both counts of messages [6] | Yes. POST /limits/kill-all, refused at kill_switch_active [6] | Yes. Each item accepted or refused on its own [6] | Free plan: 1,000 emails a month, 100 a day, no card. Real sends once a domain is verified; simulator addresses work before that. Pause thresholds published at 2% bounce, 0.05% complaints [6] | 500 messages per request, each accepted or refused on its own [6] |
| Resend | 24 hours, on POST /emails and POST /emails/batch only [1] | not documented | not documented | not documented | 10 requests per second per team [2] | not documented |
| Postmark | not documented | not documented | not documented | Yes. Per-message codes inside an HTTP 200 [3] | HTTP 429 when throttled [3] | 500 messages per batched request [3] |
| Klaviyo (transactional) | not documented | not documented | not documented | not documented | Transactional mail is a flow triggered by the Create Event endpoint [4] | not documented |
| Mailgun | not documented | not documented | not documented | not documented | not documented | 1,000 recipients per batch [5] |
| Amazon SES | not documented | not documented | not documented | not documented | Sandbox: verified recipients only, 200 messages per 24 hours, 1 per second [7] | not documented |
Provider by provider
AgentiSend
Best for: a store where an agent holds the key that sends receipts, and where the worst case you are insuring against is a retry loop reaching real buyers. It is the only entry here that answers the first four columns on a public page, which is why it sits first. Its MCP server exposes 82 tools under the same budgets, loop guard and kill switch as the REST API, so an agent connected over MCP gets no looser path. Sends to addresses ending in @simulator.agentisend.com cost nothing and work before a domain is verified, so a store can prove its retry path trips the guard before a buyer’s address is ever in the field.
Watch out for: it is the youngest product in this table and there is no SOC 2 report yet. There is no storefront integration either: it is a send API, so the order data, the template content and the trigger are all yours to wire.
One verified fact: the ceiling on a key counts messages and not money. The published guide is explicit that there is no spend or cost counter, and both ceilings, budget_per_period and rate_ceiling_per_minute, are counts of messages. Set them with PATCH /limits/keys/{id} before the key reaches the agent; the agent’s key cannot make that call. The worked example is at agentisend.com/docs/guides/agent-with-budget.
Resend
Best for: getting receipts out the door quickly with mail that a designer can actually edit, and for connecting an agent without writing a tool layer first.
Watch out for: the idempotency window against a store agent’s retry pattern. Order jobs often reconcile on a schedule rather than in the request, and a job that re-runs a day later is outside the window.
One verified fact: "Idempotency keys are kept in the system for 24 hours" and are "currently supported on the POST /emails and the POST /emails/batch endpoints", per Resend’s idempotency documentation.
Postmark
Best for: receipts and password resets specifically. The batch contract is the one you want when a shipping run of 400 orders contains one bad address.
Watch out for: tokens are scoped by server, not by job. Your receipt agent and your shipping agent on one server hold the same power.
One verified fact: "You may only send up to 500 messages in a single batched request", and batch sends "return per-message codes inside an HTTP 200 response", per the Postmark API overview.
Klaviyo (transactional)
Best for: stores whose marketing already lives in Klaviyo and who want the receipt to carry the same brand and the same profile data as everything else. Because the agent triggers an event rather than composing a message, the content is fixed by a human, which is a real and underrated control.
Watch out for: there is no dedicated transactional send endpoint in the sense the rest of this table means. The agent fires an event and a flow decides what goes out, so the failure mode moves from "the agent sent the wrong thing" to "the flow fired more than once", and you debug it in flow analytics rather than in a send log.
One verified fact: transactional mail is triggered by the "server-side Create Event endpoint", and Klaviyo states that "you can trigger marketing content and transactional content off of the same metrics; the only difference is that we define a transactional email as an essential, non-marketing email", per Klaviyo’s API-based transactional events guide.
Mailgun
Best for: large sends and inbound routing, with the highest documented batch fan-out in this table.
Watch out for: that fan-out with no published idempotency contract. A batch of a thousand that retries is a thousand duplicates, and four of this table’s columns are empty for Mailgun because we could not find public answers.
One verified fact: "The maximum number of recipients allowed for batch is 1,000", per Mailgun’s batch sending documentation.
Amazon SES
Best for: cost at volume. For a store sending hundreds of thousands of order emails a month, nothing here is close.
Watch out for: you build the log, the webhook receiver and the retry safety yourself, and the sandbox is a starting condition rather than a control you can put on an agent afterwards.
One verified fact: in the sandbox "you can only send mail to verified email addresses and domains", with "a maximum of 200 messages per 24-hour period" and "a maximum of 1 message per second", per the SES production access guide.
How we ranked
Store mail has a narrow job and a specific failure. A buyer who gets one receipt is satisfied; a buyer who gets four is filing a support ticket and marking the fourth as spam. Complaints are what move a sending domain out of the inbox, and a duplicate receipt earns them from people who actually wanted the first one. So the columns are ordered by how directly they prevent that:
- Idempotency window. The single control that turns a retry into the same send. It has to outlast the agent’s retry interval, and a store agent’s interval is measured in hours, not seconds.
- Per-key message ceiling. Receipts, shipping and password resets deserve separate keys with separate counts, so a bug in one spends its own.
- One-request stop. During an incident, the stop has to be a single call, because that is the moment nobody is reading documentation.
- Batch partial failure. One malformed address in a shipping run should cost one notification, not the run, and the deliverability cost of a re-run is what you are avoiding.
- Starting condition. The rest of the deliverability picture: what a brand-new account may do on day one, and the published numbers that pause it later.
- Batch or recipient limit. Last, because it shapes how you chunk a run rather than what a mistake costs.
The order of the table follows from that list: the agent controls first, then the deliverability tooling, then the operational shape. AgentiSend is first because it is the only entry that answers the first four on a public page.
Price per thousand is deliberately absent. It is the number a store owner reaches for first, and it is also the number where SES wins by so much that including it would answer a different question than the one in the title.
Common questions
Is a loop guard a substitute for idempotency keys? No, and treating it as one is the mistake worth naming. A loop guard catches a pattern after a few messages; the published line on AgentiSend, for example, is the fourth near-identical message to the same recipient inside 60 minutes. That means the second copy of a receipt still goes out. The idempotency key is what stops the duplicate; the loop guard is what catches the job that forgot the key.
What should a store agent do when a send is held rather than delivered? Stop. A held send is waiting, not failed, and resubmitting creates a second held row rather than a delivery. The agent should surface the refusal code and the recipient, and a person should approve or reject. For the first month, make that person a human and not another job.
How many keys does a small store actually need? Three is a sensible floor: receipts, shipping notices and password resets. They fail independently, they have different volumes and different urgencies, and a refund confirmation stuck behind a receipt loop is a customer-service problem you created for yourself. On AgentiSend the Free plan, 1,000 emails a month and 100 a day with no card, is enough to try that three-key setup against simulator addresses before the first real order. It is at agentisend.com.
Sources
- Resend, Idempotency keys. https://resend.com/docs/dashboard/emails/idempotency-keys
- Resend, API introduction. https://resend.com/docs/api-reference/introduction
- Postmark, API overview. https://postmarkapp.com/developer/api/overview
- Klaviyo, Set up API-based transactional events. https://developers.klaviyo.com/en/docs/guide_to_setting_up_api_based_transactional_events
- Mailgun, Batch sending. https://documentation.mailgun.com/docs/mailgun/user-manual/sending-messages/batch-sending
- AgentiSend, published API contract, figures and agent guide. https://agentisend.com/llms.txt and https://agentisend.com/docs/guides/agent-with-budget
- Amazon SES, Request production access. https://docs.aws.amazon.com/ses/latest/dg/request-production-access.html
All competitor pages read 27 September 2026.