Choose an email API by testing the situations your application must recover from: an unknown send result, a duplicate event, a rejected recipient, and a failed webhook. Then compare domain setup, project isolation, retained evidence, and total operating cost. A simple send example is a useful starting point; it does not establish reliable recovery or inbox placement.
Before you start #
- For
- Developers and small teams selecting email infrastructure for websites and apps.
- Bring
- Your expected recipient volume, number of projects and domains, support requirements, and shortlisted providers’ current documentation.
- Scope
- This is a provider-neutral evaluation method. The example workload is synthetic. Stampwing’s hosted accounts and sending remain unavailable until the public launch; this guide is not a claim of comparative delivery performance.
Start with the messages your app actually sends #
List the events that need email: an account confirmation, a password reset, a receipt, or a service notification. Record how quickly the message becomes useless. A reset link and a monthly usage summary need different retry deadlines.
Count recipients, not just API calls. A request addressed to several people may consume several units of allowance. Include resend requests, operational notices, incoming email if you need it, and the busiest plausible hour. Keep newsletter traffic separate so its consent, unsubscribe, and volume requirements remain visible.
| Synthetic workload | Record before comparing | Why it changes the decision |
|---|---|---|
| Three small apps | Three independently revocable keys; five sending domains | Check the actual boundary between projects and credentials. |
| 30,000 recipients per month | A 2,000-recipient burst after a batch of invoices | A monthly allowance alone does not describe throughput. |
| Password resets expire in 15 minutes | Maximum acceptable queue age and retry deadline | A late success may be useless to the recipient. |
| One developer handles support | Time needed to identify a message and its last confirmed state | Cheap sends can still require substantial operational work. |
Run the same failure checklist for every shortlist entry #
Use a local fixture or the provider’s documented test mechanism first. Keep fixtures clearly labelled and never interpret simulated acceptance as a delivered email. Ask what happens at each boundary and save the evidence next to your answer.
A provider feature can help without solving the whole application workflow. For example, provider idempotency does not automatically deduplicate your payment-webhook processing, and a signed notification does not make your handler safe to execute twice.
| Scenario | Evidence to collect | Acceptable application behavior |
|---|---|---|
| The send response is lost | Idempotency scope, retention window, and status lookup behavior | Reconcile the original operation before creating a new send. |
| The same business event arrives twice | A persisted event ID and a duplicate-request test | One logical notification survives concurrent retries. |
| A recipient is suppressed | Documented suppression result and operator visibility | Show why sending stopped; do not silently switch providers. |
| Webhook delivery is retried or reordered | Signing procedure, retry policy, replay behavior, event identity | Authenticate raw bytes and apply each state change safely. |
| A project key is compromised | Credential scope and revocation procedure | Stop that credential without exposing other projects. |
| The request exceeds a rate limit | Rate-limit response and documented retry guidance | Apply bounded backoff within the message’s useful lifetime. |
Separate sending features from delivery evidence #
Check what each status means. A successful API response can mean a request was accepted for processing. A receiving server can accept a message that later lands in spam. Ask which event supports the state you display to a customer.
Inspect domain authentication, bounce and complaint handling, suppression controls, and the evidence available to investigate a missing message. Do not rank providers by an unsupported promise of universal inbox placement. Compare documented behavior, then evaluate real operating results when you have permission and an appropriate live workload.
Compare the work around the send #
Build one worksheet per provider using the same workload. Record the plan price, included recipients, overage units, domain allowance, relevant rate limits, retained event history, content retention, and support level. Copy the source URL and review date beside each value so another person can reproduce the comparison.
Keep engineering effort explicit. Include the initial integration, domain setup, signed webhook handling, dashboards or logs you must build, and ongoing incident investigation. Avoid converting guessed support time into a precise savings claim.
{
"provider": "Fill in the provider",
"reviewed_at": "YYYY-MM-DD",
"workload": {
"monthly_recipients": 30000,
"peak_recipients_per_hour": 2000,
"projects": 3,
"domains": 5
},
"checks": {
"unknown_send_result": "Not tested",
"duplicate_business_event": "Not tested",
"webhook_retry": "Not tested",
"key_revocation": "Not tested"
},
"cost": {
"plan": "Record current quote and unit",
"overages": "Record current quote and unit",
"engineering_effort": "Record measured time separately"
},
"evidence": []
}Choose a fit and record the tradeoffs #
Prefer a managed platform when its built-in workflow removes work your small team cannot support. Consider a lower-level sending service when you already operate the surrounding queues, event processing, permissions, and diagnostics. Validate these assumptions against the actual service and plan rather than the category label.
Choose must-pass requirements before scoring conveniences. A provider that cannot meet your required data handling, credential boundary, or recovery behavior should not win because its documentation looks easier. Record unresolved questions as unknown instead of assigning them a passing score.
For an existing application, evaluate migration before choosing a destination. Preserve suppression decisions and unresolved submissions during cutover. Start with a bounded cohort and define which evidence would make you pause or roll back.
Evaluate Stampwing at its current stage #
Stampwing publishes free guides, templates, tools, and local examples now. Its hosted account, sending, and pricing pages must be read according to their current availability notices. Do not treat a local test or architecture preview as evidence of a generally available hosted service.
You can use the worksheet with any provider. Explore the local examples first, and use the public waitlist when it is available if you want Stampwing launch updates.
Sources and further reading
- Resend: sending email API fields and behavior
- Postmark: email API and response fields
- Amazon SES: understanding email deliverability
- Stampwing: reproducible local duplicate-request lab
Written for Stampwing with AI assistance and checked against the linked documentation. Examples are educational; simulated results are labelled. How these resources are maintained.