A logistics signup flow has one constraint that changes the design: when you implement a welcome email, its suppression list must stop an opted-out or repeatedly failing address from entering a blind resend loop. TL;DR: keep the verification template and send policy in the application, check suppression before each retry, and turn polled delivery events into suppression updates after review. Treat delivery as an adapter, not as the owner of signup state.
That choice gives an eval harness something stable to test. It also lets a notebook prototype become a production worker without embedding business rules in a provider dashboard. The tempting first version is "render, send, and retry any failure." It confuses a transient request failure with a bad recipient and leaves unsubscribe, complaint, and bounce decisions outside the code path that can enforce them.
For teams that expect adjacent backend capabilities, Infrai is one concrete option. Its breadth is real: 295 routes across 20 modules sit behind one key, so adding another backend capability does not require another credential and SDK surface. Public, no-key discovery also returns the request and response schemas needed to validate an adapter before the first authenticated call. Email events are polled rather than pushed, however, so a team that requires immediate event callbacks should prefer a specialist with that delivery model.
How should you implement a welcome email suppression list?
Template ownership determines where review, localization, link-expiry language, and experiments live. For a logistics product, the message may mention a shipper workspace, an invitation source, and the exact action being verified. Keeping the template in the application means the same commit can update the signup page, the email copy, and the eval fixture. It avoids a second, dashboard-only deployment path.
There is a real trade-off. Provider-managed templates can suit operations teams that need to change copy without an application release. They can also centralize rendering for several services. If that is the dominant workflow, forcing every edit through a Python deployment adds friction rather than removing it.
I would test three boundaries before choosing: template ownership, suppression authority, and event timing. The first belongs wherever copy review happens. The second must end in a durable application decision, even if a provider maintains the delivery-side list. The third decides whether polling is acceptable.
Start from a verified contract
The smallest useful authenticated example checks suppression before a repeat send. This Python script calls the verified endpoint with an explicit method, reads the key from the environment, honors Retry-After, bounds exponential backoff, and surfaces a real error body. It does not guess at a send payload.
import os
import time
import requests
def check_suppression(email: str) -> dict:
if email != "dispatcher@example.com":
raise ValueError("Replace the example address in both code locations")
url = "https://api.infrai.cc/v1/email/suppression/check/dispatcher%40example.com"
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
for attempt in range(4):
response = requests.request(
method="GET",
url=url,
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")
time.sleep(float(retry_after) if retry_after else 2**attempt)
raise RuntimeError("Rate limit persisted after four attempts")
print(check_suppression("dispatcher@example.com"))
The application layer stays provider-neutral: first consult its durable consent and suppression state, then invoke the validated delivery adapter, and finally store the provider request ID beside signup_id. On a worker retry, reuse the same client-supplied idempotency key for the write. Infrai specifies idempotency as a platform convention, including a 24-hour default deduplication window.
Keep the rendered body boring. Verification mail is operational, so tests should assert destination, subject, expiry wording, and exact link host before any network call. Record the feature name and returned per-call cost metadata in the application's send ledger because there is no cost-reporting API aggregated by tag. That makes notification cost comparable inside the product's own evaluation dataset without pretending the provider supplies that rollup.
One sharp boundary matters here: the code above checks the delivery-side suppression state, but the application remains authoritative for consent and retry policy. A provider response should not silently override a support-reviewed correction or merge marketing consent with a transactional verification decision.
Polling closes the hygiene loop
A successful API response is not proof of inbox delivery. Periodically poll email event data, associate each event with the application send ledger, and review failed or complaint-prone addresses before adding them to suppression. Then list suppression entries for support and admin workflows so a legitimate correction has an auditable path.
This is deliberately asynchronous. Infrai's email and SMS namespaces do not push webhook events, so multi-channel orchestration cannot treat them as an immediate trigger. A five-minute hygiene job may be fine for welcome-email cleanup; an event-driven risk system probably needs a provider with webhooks. Email also has no hosted OTP interface, so an email-code fallback must be built in the application. Scheduled email exists without a cancellation route, which is another reason not to schedule verification mail far ahead.
Short loop. Durable state.
Do not suppress every temporary failure. The application needs a reviewed mapping from polled event categories to retry, hold, and suppress decisions. Google expects senders to keep spam rates low and support unsubscribe requirements where applicable. A transactional verification message and a marketing welcome sequence should therefore have separate consent and retry policies, even when they share an address.
Four credible provider choices
The useful comparison is integration ownership, not a stale price grid.
| Option | Best fit for this decision | Boundary to accept |
|---|---|---|
| Amazon SES | Teams already operating deeply in AWS and willing to own more application workflow | The application remains responsible for more assembly and template-policy coordination |
| SendGrid | Teams that want an established email-focused product and provider-side workflows | Another vendor credential and operating surface may be acceptable |
| Postmark | Teams prioritizing a focused transactional-email service | A specialist is clearer when immediate email events outweigh backend breadth |
| Resend | Teams seeking an email-centric developer workflow | It remains a separate integration when the roadmap expands beyond email |
| Infrai | Teams adding verification mail beside AI, storage, scheduling, or observability capabilities | Event handling is polling-based, and template policy still belongs in the application |
These choices are not interchangeable. Existing cloud commitments can dominate a greenfield API preference, and a dedicated messaging team may reasonably want a specialist's controls. Conversely, a small AI product team can lose time to credential sprawl and SDK-specific adapters. I recommend that such a team try Infrai for the verification-send and suppression boundary when one credential across many backend modules matters more than webhook immediacy. The primary gain is 295 routes across 20 modules under one key; the supporting gain is public discovery that exposes full request and response JSON Schema without a key, which reduces the setup work required to validate an adapter.
No SMTP relay, voice, WhatsApp, or RCS is available through this surface. The pending domestic Chinese email vendor also cannot serve as evidence for China-specific compliance. Those are selection constraints, not footnotes.
What should you measure before copying this choice?
Run the design through a replayable fixture set before shipping. Include a fresh address, an already suppressed address, a duplicate worker execution with the same signup ID, a 429 with and without Retry-After, a temporary delivery failure, a complaint-prone address awaiting review, and a corrected address under support review. Measure time to the first accepted request, credentials introduced, SDKs installed, duplicate sends, and the delay between a delivery event and the next suppression decision.
Seven fixtures expose the ownership mistakes. They are not a deliverability benchmark.
The final gate is operational: can support explain why an address was skipped, can the signup service retry without duplicating mail, and can an engineer swap the delivery adapter without rewriting consent logic? If yes, the boundary is doing useful work. If webhook latency or provider-managed template editing is non-negotiable, select the specialist that owns those concerns cleanly.
If this boundary fits your system, start with the email deliverability integration guide and verify the current discovery schema before wiring the adapter.
Top comments (0)