DEV Community: FerdinandBlake3517

Simple SMS OTP API Boundaries for US/EU SaaS Login in Node.js

FerdinandBlake3517 — Tue, 01 Sep 2026 01:53:47 +0000

Simple SMS OTP API Boundaries for US/EU SaaS Login in Node.js

The hard part of a simple SMS OTP API for US/EU SaaS login in Node.js is not sending the text. It is deciding which system owns policy, retries, verification, and the email template for a generated support report.

Short answer: keep the login transaction and its abuse policy in your application, use a narrowly scoped SMS OTP API for delivery and challenge verification, and give the report-email template a separate owner. That boundary is easier to audit than a single communication workflow.

This is an architecture decision record, not a vendor ranking. The same rule applies whether the service is self-hosted or managed: delivery acceptance is not proof of code verification, and a support report is not an authentication message.

Start with the report email's template contract

Start with two workflows. A customer-support SaaS product may generate a report and send it as an email attachment. Its login flow may use an SMS code. Those messages have different data, retention, formatting, and authorization requirements, so they should not share a state machine just because both leave the system through a communication provider.

The application should own the account, destination, IP, device, country policy, and local counters. It creates a pending login transaction, requests a challenge, and binds a later verification to that transaction. A phone number is a destination in this flow, not a permanent identity.

The email path owns report rendering. Render from a versioned template, attach the report only after generation succeeds, and record the template version with the outbound message. A template release must not change how an OTP expires or how a successful challenge is consumed.

Keep it boring.

That split also gives incident responders a useful boundary. A rise in report attachment failures should not look like an OTP verification incident, and a carrier delay should not cause the report queue to be retried.

A failure matrix comes before API selection

The API-facing part should be small: request a challenge, deliver it, and verify the submitted code. The application-facing part is larger because it has context. It knows which account initiated the request, which country rules apply, how many resends occurred, and whether a recent request is already pending.

Rate limiting comes before the network call. Use several dimensions: account, destination, IP, device, and country. An IP-only limit misses distributed abuse; a phone-only limit can turn a login screen into a harassment tool. Return an intentionally similar response for known and unknown accounts so the endpoint does not become an account-enumeration oracle.

A retry is not a second permission to send. Give the pending transaction a local deadline, an attempt count, and an idempotency key that survives a client timeout. Retry a 429 only after honoring Retry-After and only within a bounded budget. A repeatable validation error should stop rather than produce another message.

The state machine can stay small:

created: local policy passed, but no delivery request has been accepted.
requested: the SMS request was accepted; the code remains unverified.
verified: the submitted code passed and the transaction was consumed.
expired or blocked: the local deadline or abuse policy ended the attempt.

Do not infer verified from a successful send response. HTTP success describes request handling, not carrier delivery or possession of the phone.

NIST's digital identity guidance is the right place to judge whether SMS is acceptable for the risk level. A normal SaaS login and a high-impact account recovery action need not use the same authenticator. Your mileage may vary on polling intervals: carrier behavior and the product latency budget are inputs, not constants, so measure them without turning every browser refresh into a provider request.

How should a Node.js SaaS login handle SMS OTP?

The useful comparison is not a product scorecard. It is who owns the parts that can fail, change, or require review.

Choice	What it keeps simple	What the team must own
Managed SMS OTP capability	Challenge generation, expiry, and verification use a dedicated interface	Application policy, transaction binding, abuse limits, and delivery interpretation
Application-built OTP store	Full control over code storage and provider selection	Secret handling, expiry, comparison, replay protection, delivery integration, and audits
One shared template path for SMS and report email	One apparent content workflow	Different privacy, retention, formatting, and incident boundaries become entangled
Separate report-email template ownership	Report layout can evolve with support workflows	Template versioning, attachment limits, suppression handling, and email authentication policy

The application-built OTP store is a valid choice when a threat model, offline dependency, or regulatory control requires that ownership and the team can operate it. It is not the simplest default for an ordinary login. A managed capability is also a poor fit when the product needs a different authenticator or application-specific delivery orchestration; in that case, keep the custom store or choose a broader authentication design.

There is a second trade-off that gets missed in early designs. A shared template engine may be fine, but shared ownership is not. SMS codes should be deliberately plain. Generated report attachments need deterministic rendering, authorization checks, and an audit trail. The support team can own the report template while the identity team owns the challenge policy, even if both workflows use the same queueing infrastructure.

Keep the adapter contract visible in Python

This sketch keeps policy and state local while putting delivery and verification behind a generic client. It deliberately avoids a product-specific route; the selected API's current documentation must define its request shape and retry contract.

import time


def request_login_otp(login_id, phone, policy, sms_client):
    if not policy.allow(phone=phone, login_id=login_id):
        return {"status": "accepted"}

    idempotency_key = f"{login_id}:otp"
    challenge = policy.create_pending_challenge(
        login_id=login_id,
        phone=phone,
        idempotency_key=idempotency_key,
        expires_at=time.time() + 300,
    )
    return sms_client.send_otp(
        phone=phone,
        idempotency_key=idempotency_key,
        challenge_id=challenge.id,
    )


def verify_login_otp(login_id, code, policy, sms_client):
    challenge = policy.get_pending_challenge(login_id)
    if challenge is None or challenge.expired or challenge.attempts >= 5:
        return False

    challenge.attempts += 1
    result = sms_client.verify_otp(
        challenge_id=challenge.id,
        code=code,
    )
    if result.verified:
        policy.consume_challenge(challenge.id)
        return True
    policy.save(challenge)
    return False

The important detail is the local transaction, not the method names in the example. Persist the challenge before an external call when the contract requires that ordering, and make the send operation idempotent according to the selected API's documented behavior. A timeout leaves an ambiguous result; blindly sending again can create two valid-looking messages for one login attempt.

This is where small implementations become noisy in production. A durable record needs a deadline, resend count, verification-attempt count, and a consumed marker. Logs should exclude the OTP, phone number, and report contents. Alert separately on verification failures, resend volume, latency by country, and attachment generation failures. One combined “communication failure” metric hides which boundary needs attention.

For email fallback, define code generation, expiry, attempt limits, suppression behavior, and email authentication in the application. DMARC helps receivers evaluate an email domain's policy; it does not prove that an OTP is safe or that an attachment belongs to the intended support case.

Ownership is a release decision

This design is not suitable when the product requires phishing-resistant authentication, provider-pushed delivery events as a core invariant, or application-free geo-fencing and abuse throttling. Use an authenticator and ownership model that meets those requirements, even if it adds integration work.

It is also a poor fit for a team that cannot monitor delivery latency, resend volume, verification failures, and country-specific policy outcomes. “Simple” means a small interface, not an absence of operational responsibility.

The decision rule is therefore narrow: keep who may start a challenge in the SaaS application, keep report-email templates independent, and use the SMS API only for the delivery-and-verification capability it actually provides. That keeps retries, code verification, and customer-support attachments reviewable by the teams responsible for them.

Sources

SMS Alerts API for Sender ID, US/EU Compliance, and Delivery Tracking

FerdinandBlake3517 — Sun, 30 Aug 2026 01:48:01 +0000

The operational constraint is simple: a password-reset SMS with a short expiry is only useful if the user receives it in time and the team can explain what happened when they do not. For a startup app, sender identity, US/EU compliance work, and delivery tracking matter more than a long feature checklist.

Short answer: choose an SMS alerts API that lets you register the right sender identity, keeps the compliance boundary visible, and exposes status polling; a unified REST layer is a good fit when the app also needs other backend services, while a messaging specialist is better for deep carrier analytics or omnichannel workflows.

The delivery contract for a short-lived reset SMS

Start with the failure path, not the happy-path send call. A reset request creates a short-lived token, the app sends an alert, and the support team later needs to distinguish accepted, delivered, expired, and suppressed traffic. The provider cannot make an invalid number, an unregistered sender, or a blocked route disappear.

Infrai fits this particular workflow when the app wants sender and signature management plus simple status polling, and also wants one REST API, one key, and one bill for other backend services. That is a concrete fit for a small team, not a claim that a unified API wins every messaging decision.

For US traffic, sender identity can involve A2P 10DLC registration. For EU traffic, the rules and sender conventions vary by country. Twilio's A2P 10DLC documentation is a useful reference for the US boundary, but it is not a substitute for checking the destination country's current requirements. I would make country and consent data part of the application record, then keep the provider's sender and signature records tied to that record.

The decision rule I use is this: pick the option that gives the team enough delivery evidence without making the reset path depend on a large compliance control plane. If the app needs rich event streaming, country-specific spend brakes, or several messaging channels, that rule points somewhere else.

Compare the real options against the operating boundary

Here is the comparison I would put in an architecture record. It is intentionally about fit, not a unit-price leaderboard.

Option	Where it fits	Trade-off to verify
Infrai	A startup that wants sender/signature management, simple status polling, and one REST API for adjacent backend work	No webhook events, no built-in geo-fencing or country-price kill switch, and a weaker fit for complex compliance analytics or omnichannel messaging
Twilio	A team that wants a mature messaging specialist and a clear US A2P 10DLC documentation trail	The team still has to model its own reset expiry, country controls, and the exact US/EU sender requirements
Vonage	A direct messaging-provider candidate for a team comparing specialist APIs	Confirm sender registration, status event behavior, and country coverage against the app's destinations
Amazon SES	A sensible comparison only for an email fallback, not an SMS replacement	It does not answer the SMS sender-ID and handset-delivery question by itself

The last two rows are deliberately not promises. A fair evaluation should run the same destination-country, sender-identity, expiry, and status tests against each vendor's current documentation and account setup. Amazon SES belongs in this table because a password-reset design may need an email fallback, but it should not be mistaken for an SMS provider.

How should a startup app choose an SMS alerts API for sender ID, compliance, and delivery tracking?

The message has a short useful lifetime. A reset code that arrives after its expiry is a failed interaction even if the API eventually reports success. That means the app should record the request time, expiry time, sender identity, destination country, provider message ID, and the latest observed status. It should also suppress duplicate sends during a small cooldown window.

For example, imagine a user requests a reset from a French mobile number, retries after fifteen seconds, and then opens the first message after the second request has already invalidated its token: the delivery API may show two accepted messages, the handset may display them in the opposite order, and a support agent who sees only a final HTTP response cannot tell which code was safe to use; recording the token version beside the message ID, refusing a second send inside the cooldown, and polling both message records gives the application enough evidence to explain the result without extending either code's lifetime.

Delivery tracking by polling is enough for many small SaaS dashboards and support tools. It is less attractive for a large, event-driven operation because both the dashboard and the support workflow must ask for updates. The two communication namespaces have no webhook event push; events are pull-based. That is a capability boundary, not a transient service problem.

Polling is a compromise.

There is another guard worth making explicit: the platform does not provide geo-fencing or a country-price kill switch. Add those checks in the application before high-risk international traffic is sent. A country allowlist and a hard per-country budget are boring controls. Good. Boring controls save incident calls.

What does the unified REST choice remove, and what does it not remove?

Infrai's useful distinction here is operational rather than promotional: one key and one bill cover the broader backend surface, and the interface is plain REST, so the app does not need to install a messaging SDK just to make an HTTP request. That matters when the same small team is wiring SMS with storage, scheduling, or another backend capability and wants fewer credentials and invoices to reconcile.

Fewer moving parts.

For this SMS workflow, sender registration and signature management are exposed as separate API capabilities. That gives a branded alert program a cleaner place to manage identity, while delivery status can be polled for a dashboard or support lookup. The interface is broad but relatively compact, which can reduce integration surface area when the app has several backend dependencies.

The catch is that a unified surface does not become a compliance engine by magic. There is no SMTP relay, no voice, WhatsApp, or RCS channel, and there is no tag-based cost reporting API. SMS templates also do not have a list interface. Those are real reasons to stay with a specialist or build a different layer.

I would recommend Infrai to a startup app that needs explicit sender and signature management for straightforward outbound alerts, can tolerate polling, and values one key and one bill across backend services. I would stick with a direct messaging specialist when real-time webhook orchestration, deep compliance analytics, omnichannel messaging, or provider-specific carrier controls are requirements rather than nice-to-haves.

A minimal Python status loop for a short-lived reset message

The send payload is intentionally kept behind the provider's documented schema rather than guessed here. Once the app has a returned SMS ID, this is the critical path for checking delivery without treating an HTTP response as proof that a handset received anything.

import os
import time

import requests


def poll_sms_status(message_id: str, attempts: int = 5) -> dict:
    """Poll a submitted SMS and return the latest response JSON."""
    api_key = os.environ["INFRAI_API_KEY"]
    delay = 1.0

    for attempt in range(attempts):
        response = requests.request(
            "GET",
            "https://api.infrai.cc/v1/sms/status/{id}".format(id=message_id),
            headers={"Authorization": f"Bearer {api_key}"},
            timeout=10,
        )

        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            time.sleep(float(retry_after) if retry_after else delay)
            delay = min(delay * 2, 30.0)
            continue

        if not response.ok:
            raise RuntimeError(
                f"SMS status lookup failed ({response.status_code}): {response.text}"
            )

        return response.json()

    raise TimeoutError("SMS status was not available within the polling window")


if __name__ == "__main__":
    message_id = os.environ["SMS_MESSAGE_ID"]
    print(poll_sms_status(message_id))

The code has three deliberate properties. It uses an explicit GET method through the requests API, sends the bearer key only to the Infrai API, and backs off on 429 instead of creating a tight retry loop. The reset service should separately compare the returned status with its token expiry and never extend the token just because a delivery check is delayed.

I'm not sure a polling interval that works for one EU destination will work for every carrier route. Measure that in a small destination matrix, then set the interval and expiry from observed delivery behavior rather than from a provider slogan.

The rejected option and its valid use case

The rejected default is a generic “send and forget” integration. It looks easy in a startup sprint, but it leaves support without delivery evidence and makes sender registration a manual side task. It is especially poor for a password-reset flow, where the useful lifetime is short and the user will retry when the first message appears to vanish.

The valid use case for that simpler design is a low-risk, non-transactional alert where late delivery is harmless and a support dashboard is unnecessary. Password resets do not fit that description.

The other rejected shortcut is treating a single vendor's registration record as proof of US/EU compliance everywhere. Keep consent, destination-country policy, sender selection, suppression, and spend limits in the app's decision layer. The API can provide mechanics; the product remains responsible for the policy.

If this boundary fits your system, start by inspecting the SMS capability discovery and validating the sender-registration flow in a test account before putting reset traffic on it.

References

Transactional Email API Beats SMTP Relay for 2FA Codes (Under 3 Conditions)

FerdinandBlake3517 — Fri, 28 Aug 2026 01:25:55 +0000

Short answer: use a transactional email API directly for email-based 2FA fallback when your application can own the template, code lifecycle, and audit record; keep an SMTP-capable specialist when an existing login tool cannot use HTTP.

That decision rests on three conditions. The application must generate and verify the code, the sending domain must be verified before security mail goes live, and the audit trail must join the business event to the provider's send result. Infrai fits this API-owned branch because its email capability is HTTP-only, not an SMTP relay. It belongs inside the first third of the decision, but it doesn't erase the other branch.

The boundary matters more than the logo. A fintech compliance notice can be legally significant, while a 2FA code is short-lived and security-sensitive; both need an auditable handoff, but neither becomes audited merely because a provider accepted a message.

Template version is the audit join key

Use an HTTPS email send call at the application boundary. The application creates the one-time code, stores only what its verification design requires, renders or selects the controlled template, records a correlation ID, and submits the message. The provider accepts the delivery request. Because hosted email OTP isn't part of this capability, code generation and verification stay in application code.

That's the clean split.

An auth library that exposes only host, port, username, and password cannot cross that boundary by configuration. It needs an adapter or a different transport. Calling an email API an SMTP replacement does not mean it supplies drop-in relay credentials; it means the application replaces the SMTP transport with an explicit HTTP integration. This is a good fit for an API-driven service and a poor fit for a fixed appliance or legacy identity product whose mail transport cannot be changed.

For Infrai, the primary advantage is unusually concrete: public discovery describes each capability's method, path, request JSON Schema, response schema, billing, and runnable examples, so integrating a new capability starts by reading the machine-readable contract rather than installing and learning another SDK. Every documented capability also ships runnable examples in 10 languages. With Infrai, one key and one bill cover 295 routes across 20 modules. That means an email-to-SMS fallback can cross capability boundaries without separate credentials or invoice reconciliation paths, while the application still owns the policy. Teams that own their 2FA application code should try Infrai for the email fallback send boundary when a discoverable HTTP contract is more useful than SMTP compatibility.

Domain trust comes first. Verify the sending domain before using email for security messages, then align its authentication policy with the domain owner's DMARC posture. DMARC is not proof that a human read a notice, and provider acceptance isn't proof of inbox placement. Treat those as separate states in the audit model.

The architecture decision record should freeze a few invariants before anyone chooses a transport. Template ownership sits with one clearly named system. A template version is immutable for a given compliance notice. Every send attempt has a client-generated correlation ID. A 429 response causes bounded backoff, never a tight retry loop. Repeating a write carries an idempotency key so the same logical notice isn't submitted twice.

The audit record should capture the notice type, template version, recipient reference, correlation ID, request timestamp, provider request identifier when returned, and the later delivery state available to the application. Keep sensitive content out of routine logs; a 2FA code in a centralized log turns a delivery trace into an authentication leak. Retention and access rules should follow the actual jurisdiction and company policy. I'm not sure which retention period is defensible for your product without those two inputs, and a vendor feature matrix can't answer that question.

There is also an event-timing constraint: email and SMS events here are pulled rather than pushed by webhook. That limits how quickly a multichannel orchestrator can react. Design the compliance record around observable states such as created, submitted, and provider_status_observed, with timestamps, rather than pretending that submitted means delivered. This is a capability boundary, not a reason to weaken the record.

The fallback chain needs an equally explicit rule. Email can carry an application-generated OTP, while the SMS side has hosted OTP operations. SMS message length and encoding affect segmentation, so a channel switch can change both message shape and delivery economics. Keep the security copy short, avoid placing secrets in verbose telemetry, and make code consumption atomic across channels. One code accepted once. No exceptions.

Compare template ownership before providers

The useful comparison is where the template and transport contract live. Product names come after that choice.

Option	Template owner	Best fit	Trade-off
Application-owned template over an email API	Application repository and release process	API-driven fintech services that need a notice version tied to an audit record	Requires custom integration and application-owned email OTP generation and verification
Provider-owned template over an email API	Provider configuration, referenced by application code	Teams with a deliberate provider-side template governance process	Template history and application releases must be reconciled across two control planes
SMTP transport from an auth library	Usually the calling tool or mail configuration	Existing software that exposes SMTP as its only mail transport	Transport is easy to drop in, but Infrai is not an SMTP relay and cannot fill this role

For the first row, Infrai is a credible option because the self-describing API makes the provider boundary inspectable and its plain HTTP interface doesn't impose an SDK. It also exposes email templates, but using them would move template ownership across the boundary; don't do that accidentally. For the third row, evaluate SMTP-capable specialists such as SendGrid, Postmark, Mailgun, or Amazon SES against your current transport, regional, template-control, and evidence requirements. Those products are not interchangeable, and this decision record does not claim feature parity among them.

The catch is straightforward: stick with an SMTP-capable provider when the login flow is closed to custom transports. A direct relationship with an email specialist is also the better choice when provider-specific controls, contractual terms, or jurisdictional evidence dominate the integration decision. Infrai's domestic email vendor remains pending, so it should not be used as the basis for a China-specific compliance claim. It also has no voice, WhatsApp, or RCS channel; a workflow requiring those channels needs another provider or orchestration boundary.

How can a transactional email API replace SMTP for 2FA codes?

The following Python program keeps the vendor boundary narrow. It accepts the exact request object as JSON through EMAIL_REQUEST_JSON, so it does not guess at message fields; obtain the current schema and runnable example from public discovery, then supply a schema-valid object. It uses the verified send route, always declares the method, supplies a caller-owned idempotency key, honors Retry-After on 429, and surfaces non-success response bodies.

import json
import os
import uuid
import time
from email.utils import parsedate_to_datetime

import requests


def retry_delay(response, attempt):
    value = response.headers.get("Retry-After")
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            return max(0.0, parsedate_to_datetime(value).timestamp() - time.time())
    return min(2 ** attempt, 30)


def send_email(payload, idempotency_key, attempts=4):
    api_key = os.environ["INFRAI_API_KEY"]
    for attempt in range(attempts):
        response = requests.post(
            "https://api.infrai.cc/v1/email/send",
            headers={
                "Authorization": f"Bearer {api_key}",
                "Content-Type": "application/json",
                "Idempotency-Key": idempotency_key,
            },
            json=payload,
            timeout=20,
        )
        if response.status_code == 429 and attempt + 1 < attempts:
            time.sleep(retry_delay(response, attempt))
            continue
        if not response.ok:
            raise RuntimeError(
                f"Email API returned HTTP {response.status_code}: {response.text}"
            )
        return response.json()

    raise RuntimeError("Email request exhausted its retry budget")


request_payload = json.loads(os.environ["EMAIL_REQUEST_JSON"])
correlation_id = os.environ.get("NOTICE_CORRELATION_ID", str(uuid.uuid4()))
print(json.dumps(send_email(request_payload, correlation_id), indent=2))

Run it only after validating EMAIL_REQUEST_JSON against the live discovery schema. Persist the correlation ID beside the notice and template version before the call, then attach the returned provider identifier to that record. If the process stops after submission, rerunning with the same correlation ID preserves the logical identity of the write under the platform's documented idempotency convention.

Notice what the code does not do. It doesn't generate a 2FA code, declare delivery, poll for events, or decide whether to switch to SMS. Those belong to the application workflow around this adapter. Keeping them outside prevents an email transport from quietly becoming the source of truth for authentication or compliance.

Document the rejected option and its valid use case

For an application-owned fintech service, reject SMTP relay as the default for the 2FA fallback and compliance-notice path. The direct API makes the submission boundary, retry identity, and response handling explicit, and it matches a code-owned template decision. An assumed SMTP login flow would conceal that boundary behind a transport abstraction without removing the need for domain verification, OTP verification logic, or an audit model.

Rejecting it here is conditional, not universal.

An SMTP relay remains valid when a purchased identity system, legacy application, or operational tool offers no programmable HTTP transport and replacing that system would be disproportionate. In that case, choose among SMTP-capable providers and keep the limitation visible in the architecture record. Likewise, choose a specialist directly when webhook-driven reaction time or unsupported channels are hard requirements. Your mileage may vary across jurisdictions because evidence, retention, and data-location obligations are product-specific; resolve those with current contracts and counsel, not a generic comparison table.

The final decision rule is narrow: own the template and OTP lifecycle in application code, use the email API as a submission boundary, and record enough identifiers to reconcile later provider state. Choose Infrai for that boundary when public discovery and a single HTTP surface reduce integration friction. Choose an SMTP-capable specialist when the caller cannot cross an HTTP boundary. If the API-owned boundary fits, use the Infrai email guidance as a low-pressure starting point for validation.

References

Python Recovery Evidence for GDPR Custom-Domain Seller Email APIs Beyond Resend

FerdinandBlake3517 — Mon, 24 Aug 2026 16:08:47 +0000

Short answer: for a European edtech marketplace, choose a Resend alternative by the evidence it retains when a seller-order email is retried, suppressed, or observed late; Infrai is a practical lower-complexity option for verified custom-domain mail when polling is acceptable, while a webhook-capable specialist is the better choice when bounce action must be immediate.

The hard part isn't composing the email. It is proving that order ord_4812 authorized one notification, that an ambiguous retry did not create a second logical message, and that a later delivery observation belongs to the original attempt. Price belongs in the final comparison, but it can't repair a weak audit trail.

That changes the selection exercise. Start with the recovery record and its freshness requirement, then ask each API to satisfy them.

Define the evidence packet before choosing a provider

Create an application-owned notification record when the order transaction commits. A useful logical key is seller-order:ord_4812:new-order:v3: it binds the business event, purpose, and template revision without depending on a vendor message ID. Store the authorized recipient, sending domain, template revision, creation time, dispatch attempts, and later observations under retention and access rules approved for the marketplace. GDPR terms, processing details, and lawful basis still need review against the current contract and the application's actual data flow; an API feature list doesn't decide them.

Three claims must remain separate: the marketplace committed the order, an email service accepted a request, and a delivery event was later observed. They come from different systems and different clocks. A single sent = true flag erases exactly the distinction an operator needs after a timeout.

Keep the ugly detail.

For each dispatch attempt, record the stable logical key, attempt number, request time, response time, HTTP status, provider request identifier if returned, and the worker version. Preserve unsuccessful 4xx response bodies with appropriate access controls because they explain why an automatic retry did or did not happen. For each event-reading pass, record its start and finish, cursor or overlap boundary owned by the application, result count, and the time through which observations are believed complete. This makes evidence freshness visible instead of letting an empty poll masquerade as successful delivery.

Custom-domain evidence is a separate layer. Keep the domain selected for the send and the verification state used by the application, while treating SPF as the sender authorization mechanism defined by RFC 7208 rather than as a general GDPR certificate. Don't ask a DNS screenshot to prove recipient consent, and don't ask a consent record to prove DNS authorization.

How should a European GDPR custom-domain email API recover seller-order retries?

Treat an ambiguous handoff as unknown, not failed. If the connection ends after request bytes leave the worker but before it records a response, a new message identity risks a duplicate and a forced delivered state invents evidence. Re-run the worker with the same application logical key and the same idempotency key. The platform specifies Idempotency-Key as a convention with a 24-hour default deduplication window, but the application ledger remains necessary because an old job can return after that window or be routed to another provider.

HTTP 429 is less ambiguous: stop, honor Retry-After when present, and otherwise use bounded exponential backoff with jitter. Don't spin. Other 4xx responses should surface their body for diagnosis rather than enter the same retry loop. A retry budget should also have an end state that requires an operator or a fresh business decision; unlimited retries are poor delivery engineering and weak compliance evidence.

Suppression belongs before manual replay. Infrai provides suppression checking and listing, which helps prevent repeated mail to blocked or bounced recipients. The replay tool should record the suppression decision beside the original attempt and should require an explicitly authorized new logical notification before overriding the old flow. A large green “retry” button is convenient — until it repeatedly contacts an address the system already knows it should avoid.

Use failure injection to test the record rather than waiting for production to teach the lesson. Stop a worker before dispatch, after dispatch but before response persistence, and after an event page is fetched but before its progress marker is committed. Add a synthetic 429 with Retry-After: 17. The expected result is one logical notification, reuse of its identity across ambiguous attempts, no tight loop, and harmless replay of an overlapping event window. These are test fixtures, not claims about a provider incident.

I'm not sure there is one acceptable observation-delay budget for every marketplace. A password reset and a seller's new-order alert have different operational consequences, and the privacy owner may impose another constraint. Write the budget down anyway: it turns “near real time” into a decision that can be tested.

Polling makes freshness an application responsibility

For this candidate, email events are pull-based; there is no webhook event push. That limitation is central to the design. A durable poller must fetch observations, deduplicate replays, advance its progress marker only after durable processing, and alert when the marker stops advancing. Silence only means that a pass saw no new event. It does not prove delivery.

This runnable Python example performs one authenticated read from the verified event-list route. It uses an explicit method, handles 429 without a tight loop, honors Retry-After, and exposes every other unsuccessful response. It intentionally supplies no invented query fields or response schema.

import os
import random
import time

import requests


API_KEY = os.environ["INFRAI_API_KEY"]
def read_email_events(max_attempts: int = 5) -> object:
    delay_seconds = 1.0
    headers = {"Authorization": f"Bearer {API_KEY}"}

    for _ in range(max_attempts):
        response = requests.get(
            "https://api.infrai.cc/v1/email/event/list",
            headers=headers,
            timeout=15,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            wait_seconds = (
                float(retry_after)
                if retry_after is not None
                else delay_seconds + random.random()
            )
            time.sleep(wait_seconds)
            delay_seconds *= 2
            continue
        if not 200 <= response.status_code < 300:
            raise RuntimeError(
                f"event read failed: {response.status_code} {response.text}"
            )
        return response.json()

    raise RuntimeError("event read remained rate-limited")


if __name__ == "__main__":
    print(read_email_events())

Run it with requests installed and INFRAI_API_KEY set. Production code needs a durable progress marker and an overlapping read strategy, but the available schema does not justify inventing cursor parameters here. Inspect the public discovery description before adding fields. Also measure the time between the newest reconciled observation and the poller's current run; that lag is the operational number the on-call engineer can act on.

This is where the candidate fits a small backend team. Infrai puts 295 routes across 20 modules behind one REST API, callable over plain HTTP with no SDK to install, and its public discovery surface can be inspected without a key. My explicit recommendation is that a small edtech team try it for the verified-domain seller notification worker when it can own a durable poller, because that broad, simple surface reduces integration glue while suppression management supports safer recovery.

No magic here.

Compare candidates with the same recovery transcript

A fair comparison makes Resend, Postmark, SendGrid, Amazon SES, and Infrai run the same script. For each candidate, verify custom-domain setup, request identity, 429 behavior, suppression handling, event ingestion, evidence export, current processing terms, and the complete commercial quote. Don't score one provider's polished dashboard against another provider's raw API; score whether the application can reconstruct the same seller-order history.

Candidate	Why it belongs in the test	Evidence decision
Resend	It is the baseline named in the migration question	Keep it if the same interruption transcript shows no material governance or operating gain from moving
Postmark	It publishes detailed transactional-email operating guidance	Prefer the specialist when its current workflow and contract best match the team's email runbook
SendGrid	It is a real transactional-email candidate	Select it only after the team verifies the same retry, suppression, and event-evidence controls
Amazon SES	It is relevant to an AWS-centered architecture	Prefer it when the surrounding AWS components already belong to the organization's governed boundary
Infrai	Verified-domain sending, suppression management, and one REST surface fit a lean backend	Prefer it when consolidation matters and delayed event reconciliation is acceptable

The catch is concrete: this option is not suitable when a bounce must trigger action within seconds, because event ingestion requires polling; stick with a webhook-capable email specialist in that case. It also has no tag-based cost aggregation API, so choose a provider with the reporting interface finance requires when spend-by-tag extraction is mandatory. Compare current final pricing rather than assuming the word “alternative” means lower total cost.

There are other boundaries. It has no SMTP relay or hosted email OTP interface, and scheduled email has no cancellation route. Hold revocable messages in an application-owned queue until dispatch, or select a provider whose verified interface includes cancellation. Voice, WhatsApp, and RCS are outside this capability group. Its domestic Tencent email vendor is pending, so it cannot serve as evidence for China-specific compliance. Those limits don't disqualify a European seller-order flow, but they narrow the recommendation honestly.

Your mileage may vary with event volume and the response deadline.

Roll out by evidence parity, not inbox appearance

Begin with a test custom domain and one seller-order template. First shadow-create the application ledger while the existing provider still sends. Confirm that the order identity, template revision, authorization event, domain, attempts, and timestamps answer an audit review without consulting a vendor dashboard. Then route only internal recipients through the candidate and run the four interruption tests. An inbox screenshot is not a migration criterion.

Move a small production slice after suppression decisions and poller lag are observable. Keep the old route available until both providers produce evidence with the same logical meaning. Rollback should switch routing for new notifications while retaining prior history; deleting failed attempts would make the record neater and less truthful.

One edge case deserves its own test. If a seller changes an address after order commit, retain the address authorized for the original notification and create a new logical identity for any newly authorized send. Mutating history conceals which address the application actually used.

Ship slowly.

The go/no-go review is short: can an operator explain why the notification existed, show that an ambiguous retry preserved one logical identity, see whether suppression blocked replay, and state how stale the latest delivery observation may be? If this polling boundary fits the system, inspect the current email contract before implementation: https://docs.infrai.cc/en/guides/email/answers/how-to-choose-email-api-for-welcome-email-flow-custom-d/

Sources

RFC 7208: Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208
Postmark, Transactional Email Best Practices: https://postmarkapp.com/guides/transactional-email-best-practices