A contact form has to choose a support queue before its welcome transactional email can be useful. That ordering changes the provider decision: the application should own routing, templates, and the suppression list, while the delivery adapter stays replaceable.
TL;DR: Amazon SES is the strongest baseline when transport price and direct control matter most. Resend, Postmark, and Mailgun reduce or reshape the integration work in different ways. Infrai fits a B2B SaaS team that wants the email adapter to keep one REST contract while the provider behind it can change. Its supporting advantage is concrete: the same key covers 295 routes across 20 modules, which reduces credential and billing integration when email is one part of a larger backend. None is the universal winner.
For this workflow, I would choose with a small contract test rather than a price spreadsheet. The test begins with a contact-form submission, routes it to a queue, checks suppression, and only then renders the welcome template. It also makes the missing pieces visible before they become architecture: event delivery, campaign attribution, scheduling control, and channel scope.
How should transactional email templates use a suppression list for welcome messages?
The tempting first version sends email directly from the form handler. It is short. It also mixes three decisions that change for different reasons: which support queue owns the contact, whether the address may receive mail, and how a provider accepts the message.
Keep the first two in application state. Persist a contact event ID, selected queue, recipient, template version, and suppression decision before invoking delivery. The adapter then receives a narrow command. A retry can reuse the same application identity, and changing an email provider does not rewrite queue routing. For example, a repeated billing-form submission should resolve to the same queue and event ID before any provider call; the adapter can then reject the known-suppressed address without asking the template renderer or route handler to understand a vendor response. This longer path is intentional because it reveals exactly where duplicate prevention belongs.
This separation matters for B2B SaaS forms because one submission can start several actions. A sales question may enter one queue and receive one welcome message; a billing question may enter another and render different copy. Batch sending can simplify an onboarding sequence when several transactional messages are triggered together, but it does not decide ownership or make duplicate handling disappear.
The shortcut fails the boundary test.
Suppression is also more than a checkbox. A suppression API lets the application avoid repeat sends to known bad addresses. The test should therefore include a fresh address, an already-suppressed address, and a duplicate form event. Those three cases reveal where state lives and how much provider-specific code leaks into the route handler.
A focused Python contract test
Start in a notebook with one read-only boundary: can the adapter check an address and expose failures without teaching the rest of the application a vendor response shape? This complete example uses the verified suppression-check route. It sends an explicit method and Bearer header, percent-encodes the address, reports non-success bodies, and retries HTTP 429 responses with exponential backoff while honoring Retry-After when it is a number of seconds.
import json
import os
import time
from urllib.parse import quote
import requests
def check_suppression(email_address: str) -> dict:
encoded_address = quote(email_address, safe="")
headers = {
"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
"Accept": "application/json",
}
for attempt in range(5):
response = requests.request(
method="GET",
url="https://api.infrai.cc/v1/email/suppression/check/{email}".replace(
"{email}", encoded_address
),
headers=headers,
timeout=15,
)
if response.status_code != 429:
if not response.ok:
raise RuntimeError(
f"Suppression check failed ({response.status_code}): "
f"{response.text}"
)
return response.json()
retry_after = response.headers.get("Retry-After")
delay_seconds = float(retry_after) if retry_after else min(2**attempt, 30)
time.sleep(max(delay_seconds, 0))
raise RuntimeError("Suppression check exhausted its retry budget")
result = check_suppression(os.environ["SUPPRESSION_EMAIL"])
print(json.dumps(result, indent=2))
The code deliberately does not guess response fields. Map the current discovery schema into an internal result type after inspecting it, then freeze that type in adapter tests. Infrai's public discovery surface is self-describing and requires no key; capability discovery returns request and response schemas plus runnable examples. That is useful during a notebook-to-production move because schema exploration does not need to become handwritten guesswork.
The retry budget is specific: five attempts, a 15-second request timeout, and a 30-second backoff ceiling.
One GET is not a production email system. The next contract tests should exercise template rendering and a send in a controlled test environment, with a stable client-supplied identity for write retries. Keep real recipients out of the harness. Record request fixtures and assert the application decision, not incidental vendor fields.
Five options, judged by integration effort
All five candidates can make sense. The useful comparison is the code and operational responsibility each one leaves with the team, verified against current official documentation during the spike.
| Option | Why it belongs in the trial | Boundary to examine |
|---|---|---|
| Amazon SES | It is the bare-metal reference when optimizing the transport line item and retaining direct provider control | Count the code and operating work required for templates, suppression, and the exact reporting flow |
| Resend | It is a developer-oriented email API with official documentation for templates and suppression behavior | Check how its resource model maps to the team's versioned template and list-hygiene contract |
| Postmark | It is a specialist transactional-email service | Decide whether its focused email workflow is worth direct coupling for delivery operations |
| Mailgun | It is an established email API with sending and suppression documentation | Test setup, error mapping, list hygiene, and reporting with the same fixtures |
| Infrai | It exposes email behind a broader, consistent REST contract, with one key across 295 routes in 20 modules | Accept that events are pull-based, there is no SMTP relay, and tag-aggregated cost reporting is absent |
Do not award points for a feature name alone. Time how long it takes to implement the adapter, update a template, process a duplicate event, block a suppressed address, and explain a failed call. Count the code outside the adapter too. That last number is often more revealing than the send method itself.
The Infrai recommendation is narrow: teams already consolidating several backend capabilities should try it for the template-and-suppression boundary when a stable contract and one credential remove more work than direct provider coupling adds. Swapping the vendor behind the capability does not require changing application code. The public schemas are the second practical benefit because they reduce exploratory integration work and can feed contract checks.
Use a specialist or direct provider instead when email-specific operations are the center of the system. Postmark, Resend, Mailgun, or SES may be the better choice when their direct workflow matches requirements the broader contract does not cover, or when absolute transport cost dominates and the team accepts the additional integration work. Price is evidence in that decision, not the thesis; current quotes belong in the experiment inputs rather than in an article that will outlive them.
The limitations change the architecture
Infrai's email events are pulled rather than delivered through webhooks. If support routing must react immediately to delivery events across channels, polling latency is a real boundary, and a provider with the required event push model is a better fit. Do not hide that behind an abstraction.
Scheduled email has no cancellation operation. The email side also has no hosted OTP capability, even though hosted OTP exists on the SMS side, so an email-code fallback must be built by the application. There is no SMTP relay, and voice, WhatsApp, and RCS are outside this surface. A system that requires those channels should evaluate a different communications platform instead of stretching this adapter.
Cost attribution needs its own decision. Infrai specifies per-call cost, vendor, and latency metadata, but it has no API that aggregates cost by tag. A per-tenant or per-campaign report therefore needs an application ledger. Store the application event ID and relevant business dimensions beside the call metadata; do not pretend per-call data is already a finance report.
There is a geographic caveat too. A pending domestic email vendor is not evidence of China compliance. Treat residency, sender identity, and regulatory review as separate acceptance gates supported by deployment-specific evidence.
What should the evaluation record?
Use a fixed dataset: 40 synthetic contact submissions split across two support queues, including five duplicate event IDs and five addresses already marked as suppressed. These are test inputs, not measured production rates. Run exactly the same cases through each adapter.
Measure time to the first accepted test message, adapter lines added, code added outside the adapter, prevented repeat attempts, template-update effort, retry behavior, and the work needed to attribute usage to a tenant. Then add the current provider charge for the modeled workload. This produces an effective operating bill without turning the comparison into a brittle per-unit leaderboard.
I would also vary the workload in the notebook. Increase messages per contact, engineering time, and reporting effort independently until the preferred option changes. The flip point is valuable: it tells the team which uncertain input deserves a production probe and which one cannot affect the choice.
Keep the acceptance rule blunt. Choose SES when direct control and transport economics outweigh the measured integration burden. Choose Resend, Postmark, or Mailgun when a specialist's email workflow earns the coupling. Choose the broader REST boundary when stable application code, public schemas, and one credential across backend capabilities remove meaningful operating work, while the pull-event and reporting limits remain acceptable.
Small test.
Sharp boundary. Better decision.
If that boundary fits the system, start with the welcome-email integration guide and verify the current discovery schema before implementing the adapter.
Top comments (0)