KoltrixChoosing a Transactional Email API: 12 Questions to Ask
Every transactional email API sends mail. The differences hide in webhooks, suppression, logs, replies and exit. Twelve questions to ask before you commit.
On this page(8 sections)
- Sending and integration
- 1. Is there an SMTP relay as well as an API?
- 2. How does it handle retries and duplicates?
- 3. What are the rate limits, and what happens when you hit them?
- Delivery events
- 4. Which webhooks exist, and are they signed?
- 5. How is suppression handled?
- Debugging and support
- 6. Can a non-engineer look up a specific message?
- 7. How long are logs and message content kept?
- 8. What does support look like when something breaks?
- Domain and deliverability
- 9. How much help do you get with domain authentication?
- 10. Where do replies go?
- Business questions
- 11. Where is data processed and stored?
- 12. How easy is it to leave?
- A comparison worksheet
- How to weigh the answers
- Key takeaways
Choosing a transactional email API usually starts with the quickstart: copy a snippet, send a test, see it arrive. Every serious provider passes that test. The differences that matter show up months later, when a customer says they never got their reset link, when a bounce storm hits, or when you want to leave.
These twelve questions are designed to surface those differences before you're committed.
Sending and integration
1. Is there an SMTP relay as well as an API?
An HTTP API is the right choice for new code. But most companies also have things that only speak SMTP: a CMS, a billing tool, a legacy service, a monitoring system. If the provider offers an SMTP relay, those can send through the same authenticated domain without code changes. If it doesn't, you'll need a second provider for them.
2. How does it handle retries and duplicates?
Your app will retry failed requests. Networks fail, and timeouts happen after the provider has already accepted the message. Ask whether the API supports idempotency keys, so a retried request doesn't send the same password reset twice. If it doesn't, you'll need to handle duplicate prevention yourself.
3. What are the rate limits, and what happens when you hit them?
Every API has limits: requests per second, messages per day or month. Find out what they are on the plan you'd buy, whether they're enforced with clear errors your code can handle, and how to raise them. Also ask what happens at your monthly allowance: are you blocked, or charged overage?
Delivery events
4. Which webhooks exist, and are they signed?
You'll want to know about deliveries, bounces, spam complaints and, depending on your needs, opens and clicks. Ask:
- Which events are available?
- Are webhook payloads signed so you can verify they came from the provider?
- Are failed webhook deliveries retried, and for how long?
- Can you also poll for events if your endpoint was down?
Unsigned webhooks mean anyone who discovers your endpoint URL can send you fake bounce events.
5. How is suppression handled?
When an address hard-bounces or a recipient marks your mail as spam, you should stop sending to it. Good providers suppress those addresses automatically. Ask whether suppression is automatic, whether you can see and edit the list, whether you can import an existing list when migrating, and whether you can export it if you leave.
Debugging and support
6. Can a non-engineer look up a specific message?
The most common email support ticket is "I didn't get the email." Someone on your support team should be able to search by recipient, see whether the message was sent, delivered, bounced or deferred, and see the reason, without asking an engineer to dig through logs.
7. How long are logs and message content kept?
Retention varies widely. Some providers keep detailed logs for days, others for months. Make sure retention covers the window in which customers typically report problems. Also ask what's stored: metadata only, or full message content? That has privacy implications as well as debugging ones.
8. What does support look like when something breaks?
Find out how you contact support, what response times are on your plan, and whether you'll reach someone who understands deliverability. Try it during your evaluation by asking a real technical question.
Domain and deliverability
9. How much help do you get with domain authentication?
You'll need SPF, DKIM and DMARC set up correctly. Some providers give you records to copy and leave it there; others check the records live and tell you exactly what's wrong. Ask about DKIM key length, whether the provider signs with your domain so DKIM aligns for DMARC, and whether you can use a custom return-path for SPF alignment.
10. Where do replies go?
This question gets skipped surprisingly often. Customers reply to receipts, password resets and onboarding emails. With most transactional APIs, those replies go wherever your Reply-To header points, often a noreply@ address or a mailbox nobody checks. Some providers offer inbound processing that posts replies to a webhook you then have to build handling for. A few, Koltrix among them, route replies into a team inbox, threaded under the original message.
Decide what you want to happen to a reply before you choose, because changing it later touches every email you send.
Business questions
11. Where is data processed and stored?
If your customers are in the EU, or your contracts specify data location, ask which regions the provider uses for sending, logs and stored content, and which subprocessors are involved. Get the answer in writing, in their privacy documentation or data processing agreement.
12. How easy is it to leave?
Every provider is easy to join. Ask what you can export: suppression lists, templates, logs. Check whether your sending code is tied to provider-specific SDKs or template formats. Keeping your code behind a thin internal interface helps regardless of which provider you choose; our guide to switching providers with zero downtime explains how.
A comparison worksheet
| Question | Provider A | Provider B | Provider C |
|---|---|---|---|
| 1. SMTP relay | |||
| 2. Idempotency support | |||
| 3. Rate limits and overage | |||
| 4. Signed webhooks, retries | |||
| 5. Automatic suppression, import/export | |||
| 6. Support-friendly message search | |||
| 7. Log retention | |||
| 8. Support quality | |||
| 9. Domain auth help, DKIM alignment | |||
| 10. Reply handling | |||
| 11. Data location, subprocessors | |||
| 12. Exit and export |
Fill it in from documentation first, then verify the most important rows during a trial.
How to weigh the answers
Not every question carries equal weight for every team. A two-person startup sending a few thousand emails a month should care most about questions 2, 5, 6 and 10: avoiding duplicates, protecting reputation, answering support tickets and catching replies. A larger team with compliance obligations will weight 7, 11 and 12 more heavily. A team migrating from another provider should start with 5 and 12.
If you want to see how three popular providers compare on some of these points, see Resend, Postmark and SendGrid compared.
Key takeaways
- Quickstarts all work; the real differences are in webhooks, suppression, logs, replies and exit.
- Insist on signed webhooks, automatic suppression and support-friendly message search.
- Ask where replies go before you send your first production email.
- Confirm data location and log retention in writing.
- Keep your code provider-neutral so the next switch is easy.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
