Choosing a transactional email API: a checklist

Most transactional email services will send a password reset. The differences show up later: what happens when a retry fires twice, what the plan does when you pass your monthly volume, where the message bodies are stored, and how much of the setup an engineer can do from code. This checklist covers the questions worth answering before you commit, and for each one it says what to test and where Boundry stands today, including the parts that are not finished.

Use it on any provider. Where a question applies to Boundry we answer it plainly, so you can hold the others to the same standard. If you are new to the topic, start with what transactional email is and come back.

Start here if the terms are unfamiliar. Read what transactional email is

1. The API shape and the SDKs

Send one real message from a terminal before you read anything else. A good API is one authenticated request with a small set of required fields, a response that returns an id, and errors that say which field was wrong. Check how the key is scoped, whether you can look a message up afterwards, and whether the provider publishes an OpenAPI contract you can generate a client from.

• Boundry: POST /emails with a Bearer project API key. Required fields are from, to, subject, and html or text. GET /emails and GET /emails/{emailId} read messages back. A key is scoped to one project and one region, and an OpenAPI contract is published at /openapi.json.
• SDKs: JavaScript/TypeScript, Python, Go and PHP are published. Ruby is a release preview. If your language is not on a provider's list, the plain HTTP API and OpenAPI contract are the fallback.
• Test: send with only html and confirm a text alternative is generated. Boundry sends both as multipart/alternative.

The send endpoint, SDK pages and framework examples are in the docs. Read the send email guide

2. Idempotency and safe retries

A timeout does not tell you whether the provider accepted the message. Without an idempotency mechanism you choose between losing a receipt and sending it twice. Ask whether a header makes a retry return the original message, and what the key should be derived from.

Boundry accepts an Idempotency-Key header on send. A retry with the same key returns the original email id instead of creating a duplicate. Derive the key from the business event, such as the order id, and not from a value generated per attempt. Test it by forcing a timeout and retrying.

3. Domain verification

You cannot send from your own domain until its DNS records are published, so this is where first-day time goes. Look at how many records you publish, whether the provider tells you exactly what each one is for, whether you can re-run verification without recreating the domain, and whether the From address is rejected until the domain is verified.

In Boundry, a domain belongs to one regional project and must be verified before a From address on it is accepted. You publish the generated DKIM, SPF and MX records, then select Verify or call the verify endpoint. The docs recommend a subdomain for sending, and a dedicated subdomain for inbound so you never redirect your company's normal mail.

The steps and records are written out in full. Follow the domain verification guide

4. Events and webhooks

An accepted request is not a delivered message. You need to know about bounces and complaints without polling. Check which events exist, whether deliveries are signed, whether you can fetch missed events later, and what happens to an endpoint that keeps failing.

• Boundry events include email.sent, email.delivered, email.delivery_delayed, email.bounced, email.complained, email.unsubscribed and email.failed. You list the exact events you want when you create a webhook.
• Deliveries are signed and carry an id that stays the same across retries, so you can deduplicate. Verify the signature on the raw body before parsing it.
• Boundry disables a webhook endpoint after repeated failed deliveries and emits a webhook.endpoint.disabled event, so keep your receiver fast and return a success response once the event is queued.
• Open and click events appear in the event catalogue, but check the events reference before you rely on them: they are marked as not yet produced. Do not build a dashboard on engagement data until they are.

Signature headers, event names and a verification example are documented. Read the webhooks guide

5. Limits, plans and what happens at the cap

Pricing pages list a monthly volume. They are less clear about what happens on day twenty when you pass it. Ask whether sending continues and bills overage, or stops. Also check the sending domain limit per plan, because agencies and multi-product teams hit it first.

• Sandbox: $0 a month, 3,000 emails, 1 sending domain, 1 active region.
• Developer: $25 a month, 50,000 emails, 10 sending domains, 1 active region.
• Business: $250 a month, 500,000 emails with graduated usage pricing up to 2 million, 1,000 sending domains, 3 active regions.
• Enterprise: custom.
• Sandbox and Developer pause additional sending after the included monthly volume until you upgrade or the next billing month begins. Build an alert on your own send counts so a pause is never a surprise.
• Paid checkout is not yet self-serve. Prices are in US dollars.

Plans, limits and the estimator are on the pricing page. See pricing

6. Region and where the data lives

Message bodies, recipient addresses and event logs are personal data. Ask where they are stored, whether you choose the location, whether it can change later, and what sits outside the boundary. A privacy reviewer will ask the same things, and a clear written answer saves a round trip.

Boundry binds each project to one region when it is created, and that region is permanent. The project's message operations and configured application storage run in that region. Sydney (ap-southeast-2) is the only live region today; other regions are requestable, and a request records demand without promising a launch. Disclosed exceptions: public requests transit Cloudflare, Clerk handles account identity in the control plane, and a recipient's mailbox provider holds the message after delivery.

Two things are not finished, and you should know before you rely on them. Configurable retention is not yet enforced, so if you need a fixed deletion window for sensitive mail, Boundry does not meet it today. Native inbound email is deployment-gated rather than generally available.

The boundary, including what is not yet verified, is written up. Read the regional architecture

7. Support for AI agents

If coding agents or assistants will set up or operate your email, check whether the provider offers more than a docs page. Look for a hosted MCP server with scoped approval, an installable skill, and an API contract an agent can read without guessing.

Boundry runs a remote MCP server at api.au.boundry.dev/mcp. A client discovers OAuth, you approve access to one Sydney project, and the grant can be revoked. An Agent Skill installs with npx skills add flindev/boundry-skills. Sign-in, DNS changes and sending to real recipients stay with a human.

Setup and the approval flow are in the agents guide. Connect an AI agent

8. What is in preview or in development

Boundry's current availability:

• Live: Sydney region, the send, domain and webhook APIs, JavaScript, Python, Go and PHP SDKs, the MCP server and Agent Skill.
• Preview: Ruby SDK, and Automations (multi-step sequences with triggers, filters, delays and email, Slack and HTTP actions).
• Not yet: additional live regions, self-serve paid checkout, enforced retention controls, generally available inbound.

We do not publish deliverability rates, uptime figures or benchmarks, so we will not quote any. Ask every provider, including us, for the numbers they will put in writing, and run your own test sends to the mailbox providers your users actually use.

A one-page version

• Send one message by raw HTTP and read it back.
• Force a timeout and retry with an idempotency key. Confirm one message arrives.
• Verify a subdomain and time how long it takes.
• Receive a bounce event on a signed webhook and verify the signature.
• Write down what happens at the monthly cap on the plan you will use.
• Get a written answer on where bodies, addresses and logs are stored, and what sits outside that boundary.
• Check the gaps list: retention, inbound, regions, checkout.
• If agents will touch it, connect one and see what you have to approve.

Frequently asked questions

What should I look for in a transactional email API? Look for a simple authenticated send request, idempotent retries, a clear domain verification process, signed webhooks for bounces and complaints, plan limits you understand, a stated data location, and honest documentation of what is not finished.

What is the difference between an email API and an SMTP relay? An email API takes a structured HTTP request and returns an id you can look up, which makes retries and event handling easier to build. An SMTP relay accepts mail from software that already speaks SMTP. Boundry's documented interface is the HTTP API and its SDKs.

What happens when I reach my monthly email limit on Boundry? On the Sandbox and Developer plans, additional sending pauses until you upgrade or the next billing month begins. Business adds graduated usage pricing up to 2 million emails a month.

Where does Boundry store email data? Each project is bound to one region for its lifetime, and message operations and configured application storage run there. Sydney is the only live region today.

Can I use Boundry from an AI agent? Yes. Boundry has a remote MCP server with OAuth approval for one project and an installable Agent Skill. Account sign-in, DNS changes and sending to real recipients stay with a person.

Send your first message in a few minutes. Follow the quickstart