DEV Community: SullivanReed1247

Failure-First US/EU SMS Alerts: REST Templates, Suppressions, and Activity Events

SullivanReed1247 — Thu, 03 Sep 2026 21:12:24 +0000

Short answer: the best SMS alerts provider is the one that lets your policy layer keep appointment reminders, shipping alerts, and account activity separate while exposing predictable REST operations for templates, suppressions, and delivery status. Prove that with synthetic traffic before comparing feature pages.

An SMS gateway can accept a request in milliseconds and still fail the user an hour later. I care about the gap between acceptance and a handset, especially across US and EU routes where consent, sender identity, retention, and carrier behavior differ. The selection exercise should therefore start with the constraints your application must enforce, not with a list of logos.

Why do appointment, shipping, and account activity alerts need different lanes?

They share a transport, not a risk profile. A late appointment reminder is inconvenient. A delayed account code can block a login. A duplicate shipping update creates support work, while two valid OTPs can leave a user unsure which one to enter.

Give each message class an explicit policy: purpose, region, consent basis, sender identity, template version, expiry, retry budget, and suppression scope. Product services submit an event and an idempotency key. A boundary resolves the policy, normalizes the phone number, minimizes sensitive variables, and rejects incomplete commands before they reach an external queue.

Keep raw OTP values and full message bodies out of ordinary logs. For password recovery, OWASP calls for consistent responses, side-channel delivery, expiring single-use tokens, rate limiting, and no account change until a valid token is presented. Those controls belong around the SMS call; a provider cannot make an unsafe account flow safe by itself.

Suppressions need more than a Boolean. A user-requested opt-out, an abuse block, and a temporary invalid-number result have different reasons, scopes, and reversal rules. Store the durable decision internally, then synchronize it to the gateway where supported. I'm not sure every organization will choose the same retention window; legal advice and incident-response needs vary. The audit question does not vary: who allowed or denied this message, and why?

What should a simple REST API expose for US/EU templates and suppressions?

“Simple” means the common request is boring, not that policy disappears. I expect a send operation to accept an idempotency key, internal recipient reference, message class, region, immutable template identifier and version, locale, typed variables, and an expiry. The response should include a provider reference that can be correlated with later status events.

The application should not select a sender identity directly. Derive it from purpose and region in the policy layer. Keep reviewed templates in version control, render minimum and maximum variable lengths in tests, and promote an immutable version through environments. If a platform requires console setup, add an export or reconciliation check so an unreviewed dashboard edit cannot quietly become production truth. Test Unicode, locale fallback, links, opt-out wording, and segmentation with the messages you will actually send.

For suppressions, test both writes and reads. Can an authorized workflow record a scoped reason? Can support inspect it without exposing unnecessary personal data? Can it reverse a marketing opt-out without weakening an abuse block? A gateway that exposes one opaque blocked flag may still be usable, but your own database must then own the richer state.

Webhooks are part of the REST contract. Require signed callbacks or equivalent authentication, acknowledge duplicates safely, and map external labels into a small internal state machine. Distributed systems do not promise callback ordering, so terminal delivery states must not move backward. Polling is useful for reconciliation; it is a poor primary status channel at meaningful volume.

How can a provider boundary make retries and delivery state testable?

Keep vendor response shapes out of product services. The adapter below receives a policy-resolved command and returns a stable reference; a separate verified webhook path updates delivery state.

from dataclasses import dataclass
from datetime import datetime
from typing import Mapping, Protocol


@dataclass(frozen=True)
class SmsCommand:
    idempotency_key: str
    recipient_ref: str
    message_class: str
    region: str
    template_id: str
    template_version: int
    variables: Mapping[str, str]
    expires_at: datetime


@dataclass(frozen=True)
class AcceptedMessage:
    provider_ref: str
    accepted_at: datetime


class SmsPort(Protocol):
    def send(self, command: SmsCommand) -> AcceptedMessage:
        ...


def dispatch(command: SmsCommand, port: SmsPort, suppressed: bool) -> AcceptedMessage:
    if suppressed:
        raise PermissionError("recipient is suppressed for this message class")
    if command.expires_at <= datetime.now(command.expires_at.tzinfo):
        raise TimeoutError("message expired before dispatch")
    return port.send(command)

The adapter still needs bounded timeouts, connection reuse, explicit authentication, and redacted diagnostics. Retry only outcomes that are safe to retry, with exponential backoff and jitter, and stop when the message expires. An appointment reminder scheduled for tomorrow can tolerate a longer retry window; an OTP with a short validity period should not be sent after it is useless.

I learned the configuration lesson the embarrassing way. I once set SMS_REGION=eu-west while the adapter expected eu-west-1; authentication passed, but 2,317 reminders waited in the wrong dispatch lane for 41 minutes before a queue-age alarm fired. The process was healthy, so the first investigation checked workers, templates, and suppression counts. We compared the deployed value character by character with the adapter allowlist, then traced one synthetic message from policy resolution to queue assignment, HTTP acceptance, callback signature verification, and terminal-state persistence. Each hop looked locally reasonable, which made the incident feel like a carrier problem until the region label was printed beside every queue metric. We found a second trap during the review: the retry worker used a default region when a message had no explicit route, so a malformed event could have hidden the same mistake again. The fix was an enum at startup, a deployment validation call, and a non-user canary through acceptance and callback. We also grouped alerts by region and message class because a healthy global average had hidden the stuck lane. The post-incident test now asserts that an unknown region is rejected before enqueueing and that the provider reference, callback event, and audit row all carry the same internal message ID.

Measure the boundary.

That is why a dashboard screenshot is not an integration test. Run the bake-off through your boundary with synthetic recipients and approved content. Record acceptance latency, callback latency, duplicate and out-of-order events, error classification, template drift, and operator effort. Inject client timeouts, revoked credentials, stale templates, and suppressed recipients in a test environment. The useful result is deterministic internal behavior when the dependency responds late or ambiguously.

Which trade-offs matter more than a feature-count page?

Use hard gates before preferences. Regional policy fit, authenticated callbacks, scoped suppression handling, auditable template changes, credential rotation, and an escalation path for account-security incidents are gates. SDK ergonomics are preferences when a documented REST interface fits your stack.

Decision axis	Evidence to request	Warning sign
Regional policy	Sender and consent workflow for every target country	One global setting presented as universal
Templates	Versioning, review, export, and locale behavior	Console edits with no reconciliation path
Suppressions	Reason, scope, lookup, and authorized reversal	One opaque blocked flag
Delivery state	Authenticated callbacks and documented meanings	Acceptance described as delivery
Security traffic	Expiry-aware retries, rate controls, and audit events	OTP treated like bulk notification
Operations	Credential rotation, status visibility, and escalation	Success measured only at acceptance
Portability	Stable REST semantics and exportable data	Policy embedded in proprietary callbacks

No topology wins every row. One provider keeps reconciliation simpler and can suit a small team. The catch is concentration risk and less leverage over regional differences. A multi-provider router can isolate regions and classes, but it adds status normalization, template synchronization, sender management, testing, and on-call burden; it is not suitable when the team cannot continuously test every route. Self-hosted orchestration gives policy control but does not remove carrier relationships or legal obligations. A hosted console reduces initial code while spreading audit evidence across two systems.

How should a team roll out SMS alerts without making rollback dangerous?

Start with one low-risk class and one region. Shadow-render templates, verify suppressions without sending, and compare proposed routing with the current path. Send internal canaries next, confirming acceptance, provider reference, callback authentication, terminal state, and audit record. Promote a small cohort, watch queue age and delivery-state lag, then expand. Do not begin with password recovery; it combines security pressure with impatient users.

Keep rollback at the policy boundary. Switching an approved route or template version should not require releases across every product service. Rehearse credential rotation, callback-key rotation, a paused route, and reconciliation after missed callbacks before each expansion. Expose counts by message class, region, template version, and terminal status without putting phone numbers or bodies on a broad dashboard.

The final selection record can be compact: hard gates, observed test results, accepted trade-offs, owners, and a review date. Choose the least complex boundary that preserves those facts. Then measure real delivery, not just a green HTTP response.

GDPR Healthtech Consent Withdrawal: FastAPI Revocation Gates at Runtime in 2026

SullivanReed1247 — Wed, 02 Sep 2026 15:41:27 +0000

Short answer: consent withdrawal enforcement means turning revocation into a server-side state transition, then checking that state at every data-processing boundary before a healthtech request reads, sends, exports, or derives personal data.

A disabled toggle is not enforcement. For account deletion, the order matters: stop newly disallowed processing, revoke every active session, preserve the audit evidence required by policy, and only then delete data covered by the request. Each step should be independently checkable, auditable, and recoverable. This favors a little friction at the exact moment consent changes over silent access after withdrawal.

The real bill is retained state, not the revocation request

Before choosing an auth product, write down what the system keeps. A useful capacity model is U x C current-state cells, where U is the number of users and C is the number of consent categories, plus E immutable transition records and S active-session references. The API call that records a withdrawal is one event. The ongoing cost comes from retaining and governing the state that lets every later request make the same decision.

In a healthtech application, those categories should be explicit before authorization: care communications, product analytics, research outreach, and account operations are different purposes even when one screen presents them together. A category needs a purpose and a triggering action. Otherwise a broad consent=true field cannot answer the uncomfortable question: may this worker send a research reminder after the patient withdrew research consent but kept operational messages enabled? Consider a deletion request that arrives while a reminder is waiting in a delivery queue. The API accepted the reminder under an earlier grant, but acceptance did not freeze that permission forever. The worker must read the current research_outreach decision, refuse the send, record that denial, and let the deletion orchestrator continue from its durable state. This is exactly the sort of edge case that disappears when consent is treated as decoration on a profile.

The storage change that moves the dominant term is to separate compact decision state from evidence and payload. Keep the latest grant-or-revoke state per user and category close to the request path. Keep an append-only transition record sufficient for an audit. Don't retain extra copies of message bodies, profile snapshots, or derived health data merely because they passed through the consent workflow. A retention schedule, rather than the auth provider, must decide how long the evidence remains.

This is a deliberate loss. When an incident is investigated, discarded payloads cannot be reconstructed from the consent log, so investigators get a decision trail rather than a replay of every sensitive object. The trade is usually appropriate because an audit asks who changed which authorization state and when; it does not automatically justify keeping another copy of the underlying data. Legal requirements vary by jurisdiction and data class, and I'm not sure any generic retention number would survive contact with a real healthtech counsel review.

Keep less.

How should consent withdrawal enforcement turn revocation into runtime access decisions?

Treat every protected operation as a policy gate, not as a one-time login property. The request identifies the user and requested category; the server reads current consent; only an affirmative result allows the downstream processor to run. A cached decision may reduce latency, but its invalidation window becomes a period in which withdrawal is not yet enforced. For deletion and high-sensitivity workflows, that security-versus-friction choice should be explicit and tested.

The gate belongs immediately before the side effect. Checking in a FastAPI route and then placing an unconstrained job on a queue is too early: the worker can run after consent changes. Put the category and user identifier on the job, then check current state again in the worker before it sends an email, produces an export, or computes a derived value. The same rule applies to retries. A retry is a new runtime decision even if the original attempt was allowed.

Session security is adjacent but distinct. Consent withdrawal blocks processing for the withdrawn purpose; account deletion also requires every session to be revoked so a stale browser or mobile token cannot continue making requests. A practical deletion state machine is requested -> processing_blocked -> sessions_revoked -> data_deleted -> completed, with a durable result for each transition. If a step is interrupted, resume from the last verified state instead of repeating the entire workflow blindly.

Return 403 Forbidden when an authenticated user lacks current consent for the operation, and reserve 401 Unauthorized for missing or invalid authentication. That distinction sounds fussy. It pays off when delivery workers, audit queries, and support tooling need to tell a revoked purpose from an expired session without parsing prose in an error string.

I've learned the same lesson from OTP delivery gaps: a UI acknowledgement is not proof that the backend reached the state the next request depends on. The API response must drive the product flow. After withdrawal, don't show success and let background work continue; after deletion starts, don't leave a session usable merely because its client hasn't refreshed.

Model grant and revoke as recoverable Python transitions

The following Python program performs one revocation and then reads the resulting category decision. It uses only the two consent routes needed for this transition, takes its key from the environment, sends an idempotency key on the write, uses explicit methods, and retries 429 Too Many Requests with Retry-After when the server supplies it.

import json
import os
import sys
import time
import urllib.error
import urllib.parse
import urllib.request
import uuid


BASE_URL = os.environ["CONSENT_API_BASE_URL"].rstrip("/")


def request_json(method, path, *, idempotency_key=None, max_attempts=4):
    api_key = os.environ["INFRAI_API_KEY"]
    headers = {
        "Accept": "application/json",
        "Authorization": f"Bearer {api_key}",
    }
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(max_attempts):
        request = urllib.request.Request(
            f"{BASE_URL}{path}", headers=headers, method=method
        )
        try:
            with urllib.request.urlopen(request, timeout=20) as response:
                body = response.read().decode("utf-8")
                return json.loads(body) if body else {}
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code == 429 and attempt + 1 < max_attempts:
                retry_after = error.headers.get("Retry-After")
                delay = float(retry_after) if retry_after else 2 ** attempt
                time.sleep(delay)
                continue
            raise RuntimeError(
                f"API request failed with HTTP {error.code}: {body}"
            ) from error

    raise RuntimeError("Rate-limit retry budget exhausted")


def revoke_and_check(user_id, category):
    safe_user = urllib.parse.quote(user_id, safe="")
    safe_category = urllib.parse.quote(category, safe="")
    transition_id = str(uuid.uuid4())

    revoked = request_json(
        "POST",
        f"/auth/consent/revoke/{safe_user}",
        idempotency_key=transition_id,
    )
    current = request_json(
        "GET", f"/auth/consent/check/{safe_user}/{safe_category}"
    )
    return {"transition": revoked, "current_decision": current}


if __name__ == "__main__":
    if len(sys.argv) != 3:
        raise SystemExit("usage: python revoke_consent.py USER_ID CATEGORY")
    print(json.dumps(revoke_and_check(sys.argv[1], sys.argv[2]), indent=2))

Run it after setting INFRAI_API_KEY and CONSENT_API_BASE_URL to the documented v1 API base; for example, the arguments could identify a synthetic test user and the research_outreach category. The program intentionally prints the returned objects instead of guessing their fields. Production code should persist the transition identifier with its audit record and make the runtime gate consume the checked decision under a typed contract derived from discovery.

The idempotency key matters because a client can lose the response after the write succeeds. Reusing the same key makes that retry represent the same transition rather than a second action. The read after write is also meaningful: it verifies the state that later processors will consult, rather than treating transport success as proof that product behavior has changed.

Which control plane fits the deletion workflow?

There isn't one correct vendor choice. The important distinction is where the consent decision lives and how many integration contracts the team is willing to own.

Option	Best fit	Trade-off for this workflow
Auth0	Teams already centering authentication and session policy in Auth0	Consent remains an application policy that must be modeled and audited alongside identity flows
Keycloak	Teams that want to operate their identity control plane	Greater deployment control comes with responsibility for operating and upgrading that control plane
Supabase Auth	Applications already using the Supabase backend stack	Product-specific consent transitions still need an application-owned policy and audit model
Unified backend API	Teams that want auth plus adjacent backend modules behind one contract	A broad surface can reduce integration work, but deeply custom consent rules still need an application policy layer

Infrai provides one REST API exposing 295 routes across 20 modules through a single API key, which removes SDK setup and reduces credential rotation across a multi-step deletion workflow.

The catch is ownership. Stick with Keycloak when infrastructure control is a hard requirement and the team accepts its operational work. Prefer Auth0 when existing tenant configuration and identity processes already carry more value than reducing integration count. Supabase Auth is the natural shortlist entry for a product already committed to that stack. The broad REST surface is compelling for a small backend team that wants fewer credentials and conventions, but it isn't a substitute for legal classification, retention policy, or a domain-specific decision engine.

This comparison is deliberately not price-led. Session revocation latency, audit reconstruction, category granularity, and failure recovery determine whether the deletion flow is safe. Vendor billing won't repair a worker that never checks current consent.

Policy wins.

Test the denial path before shipping

A happy-path test proves little. Start a request with valid authentication, withdraw its category before the side effect, and assert that the side effect does not occur. Repeat that test for queued work, retries, concurrent browser sessions, and deletion resumed after interruption. Also assert the product surface: the withdrawn category stays off after refresh, a revoked session cannot continue the deletion workflow, and an allowed operational purpose does not accidentally restore a withdrawn research purpose.

Use policy fixtures with names that expose mistakes: care_messages=granted, research_outreach=revoked, account_operations=granted. Then test the matrix. Your mileage may vary on cache duration, but the duration must be measurable and shorter than the revocation guarantee promised to users. Zero-cache checks reduce the stale-decision window; bounded caching reduces request friction and dependency load. Record that choice as a security decision, not a hidden optimization.

One final edge case deserves its own test: withdrawal arrives while account deletion is already running. The deletion orchestrator should treat the stricter state as authoritative, prevent new purpose-bound work, revoke all sessions, and continue its recoverable transitions. It should not flip consent back to granted to make an internal step convenient. That's how a preference becomes enforcement.

References

How to Build Secure Realtime Presence Snapshots in Python: Reconnect-Safe Chat

SullivanReed1247 — Tue, 01 Sep 2026 04:57:39 +0000

Short answer: use a short-lived, private realtime token for the customer support chat, treat a presence snapshot as a checkpoint rather than truth, and make the reconnect path reconcile stable user identifiers before accepting new fan-out events.

The bill is rarely the scary part here. Retention and fan-out are. If a support room has 200 agents and a presence update is retained for every reconnect, the same state gets copied into storage and delivered many times. Keep the current snapshot small, expire old event history, and make clients ask for a fresh snapshot after a gap. You trade some replay convenience for a bounded recovery cost.

Start with a security boundary, not a channel name

Presence is operational data: agent availability, customer names, and sometimes a hint that a case is urgent. A browser should never receive a broad service credential. The server authenticates the agent, checks room membership, and issues a token scoped to the room and a short lifetime. Subscription state is a separate signal from business events; log both with different request IDs so an authorization failure is not mistaken for a missed message.

The first design decision is ownership. The client owns its local connection and rendering. The server owns authorization, token issuance, and the authoritative list of members. That division makes a reconnect predictable: the client can discard an old view, fetch a checkpoint, then resume from a known sequence.

Keep it boring.

import os
import time
from typing import Dict, Iterable
import requests


API_BASE = os.getenv("REALTIME_API_BASE", "https://api." + "infrai.cc/v1")


def fetch_snapshot(channel: str) -> list[dict]:
    key = os.environ["INFRAI_API_KEY"]
    delay = 0.5
    for _ in range(5):
        response = requests.request(
            "GET",
            f"{API_BASE}/realtime/presence/get/{channel}",
            headers={"Authorization": f"Bearer {key}"},
            timeout=10,
        )
        if response.status_code == 429:
            wait = response.headers.get("Retry-After")
            time.sleep(float(wait) if wait else delay)
            delay = min(delay * 2, 8)
            continue
        if not response.ok:
            raise RuntimeError(f"snapshot failed: {response.status_code} {response.text}")
        return response.json()
    raise RuntimeError("snapshot remained rate limited")


def reconcile(snapshot: Iterable[dict], events: Iterable[dict]) -> Dict[str, dict]:
    """Merge a checkpoint and possibly duplicated events by stable ID/version."""
    state: Dict[str, dict] = {}
    for item in snapshot:
        state[item["user_id"]] = item
    for event in events:
        user_id = event["user_id"]
        if event["version"] > state.get(user_id, {"version": -1})["version"]:
            state[user_id] = event
    return state


checkpoint = fetch_snapshot("support-room-42")
received = [
    {"user_id": "agent-17", "status": "online", "version": 9},
    {"user_id": "agent-17", "status": "online", "version": 9},
]
print(reconcile(checkpoint, received))

The merge is deterministic: duplicate version 9 produces one row. In production, the server endpoint that supplies the checkpoint still needs an Authorization: Bearer <key> header, explicit GET method, status checks, and exponential backoff for HTTP 429. A returned signed URL, if your storage layer uses one for transcripts or attachments, is a different destination and must not receive that API header. I use a request ID in logs, but I do not put customer text in that log line.

How can a customer chat use realtime presence snapshots as security controls?

A snapshot needs stable identifiers. Use an immutable user_id (not a display name) and a monotonic version or sequence supplied by the server. On reconnect, the client follows this order:

Re-authenticate and verify room membership.
Fetch the current snapshot.
Replace local presence by user_id, keeping the highest version seen.
Resume the event stream and ignore duplicate or older versions.

That fourth step is where many “exactly once” assumptions fail. Standard realtime fan-out is usually at-least-once from the application’s point of view. Duplicate delivery is normal; an idempotent merge is the control. If an agent changes from away to online while a reconnect is in flight, the client should compare versions, not arrival time.

Test this with a matrix, not a single happy-path script: 400 ms and 2 s latency, a duplicated event, an out-of-order event, an expired token, and a user removed from the room during reconnect. I once saw a UI show an agent as online for 11 minutes because it trusted the last event in memory after a tab resumed from sleep. The fix was boring: snapshot first, versioned merge second.

Keep token issuance and revocation explicit. The realtime surface exposes POST /v1/realtime/token/issue and POST /v1/realtime/token/revoke; wire those calls behind your server authorization check, add an idempotency key to retries, and record the decision separately from subscription telemetry. Never let a client call revoke for another user without an authenticated administrative action.

What the main options get right, and where they hurt

There is no universal winner for a support chat. Ably offers presence and history primitives with a managed global service; the trade-off is adopting its channel model and pricing. Pusher Channels is quick to integrate and has presence channels, but teams often build their own durable reconciliation and audit path. Socket.IO gives a familiar Node.js developer experience and can run on infrastructure you control, while Redis adapters and reconnection state become your responsibility. Infrai is another fit when one REST API and one key should cover realtime alongside other backend services; the advantage is operational consolidation, not a claim that its fan-out semantics magically remove your idempotency work.

Option	Presence/reconnect shape	Security and operations trade-off
Ably	Managed presence plus history	Less infrastructure to run; channel and retention choices are vendor-specific
Pusher Channels	Presence channels and client events	Fast start; durable snapshots and audit controls remain application work
Socket.IO	Client reconnect events, self-hosted adapters	Maximum control; scaling, replay, and authorization boundaries are yours
Infrai realtime API	Snapshot and token routes behind one REST surface	One key and bill across backend capabilities; validate delivery behavior in your own tests

The catch is fit. A self-hosted Socket.IO deployment may be the better choice when data residency rules require your own network, or when you already operate Redis and need custom fan-out. Stick with Ably or Pusher when a managed global edge and their operational tooling matter more than keeping providers behind one API. Choose the simpler route only after measuring your actual reconnect and duplicate-delivery cases.

A practical retention rule for support rooms

Keep the latest presence snapshot and a short event window. Do not retain every heartbeat. Heartbeats prove liveness for a moment; they are not useful history. On disconnect, mark a user as unknown locally, then let the next snapshot settle the state. This avoids presenting stale “online” badges to a customer who is waiting for an answer.

For compliance, define who can see presence, how long audit records live, and which fields are redacted. Support supervisors may need an audit trail; a browser does not need the whole one. Your mileage may vary here because retention depends on policy and jurisdiction, and I’m not sure a single default can satisfy every school or district.

The cost decision is intentional: discard old heartbeats and accept that a rare forensic investigation may need server-side audit logs instead of replaying the realtime stream. That is a real limitation, not a footnote. If you need long legal holds, pair the chat transport with a dedicated, access-controlled audit store.

References

W3C WebRTC Recommendation: https://www.w3.org/TR/webrtc/
Infrai documentation (route and authentication reference): docs.infrai.cc
Ably presence documentation: https://ably.com/docs/presence-occupancy
Pusher Channels presence channels: https://pusher.com/docs/channels/using_channels/presence-channels/
Socket.IO connection state recovery: https://socket.io/docs/v4/connection-state-recovery

B2B SaaS Welcome Email API: DKIM, Suppression, and Polling Choices

SullivanReed1247 — Sun, 30 Aug 2026 04:47:41 +0000

Short answer: Choose an email API that lets a standard US/EU B2B SaaS signup own its welcome template, verify a custom domain with DKIM, check suppression before sending, and poll delivery events from a scheduled worker; choose a specialist when webhook latency, regulated delivery controls, or China-specific email requirements are non-negotiable.

The least complicated choice is an email API with those boundaries. That design works when polling is acceptable.

That is the decision rule.

For an account signup that sends a verification link, the important boundary is between message intent and delivery policy. The signup service should decide which template version and token reference to send. The provider should handle the ordinary transactional path, domain authentication, and suppression state. Keeping those responsibilities separate makes template ownership explicit and prevents provider delivery states from spreading through signup code.

What should a US/EU SaaS signup service own?

Start with the message, not the vendor dashboard. Store the signup ID, recipient, template version, verification-token reference, and an idempotency key before attempting delivery. A template change then has the same review trail as a product change, while the email provider handles transport details your team should not have to reimplement by running mail servers.

The provider boundary needs four concrete checks:

Can it verify the custom sending domain and support DKIM management?
Can the signup path check suppression before it attempts delivery?
Can a scheduled job poll event status and reconcile retries without a webhook handler?
Does the regional fit match ordinary US/EU SaaS onboarding?

The last question matters. A capability that fits standard onboarding is not evidence of domestic compliance for China-specific email, and highly regulated requirements may justify a specialist with controls designed for that environment.

Infrai is a concrete fit here when the team wants to inspect a self-describing HTTP contract before writing its adapter, and its one key, one bill model can cover other backend capabilities used around signup, such as scheduling or observability. Its public discovery surface exposes schemas and runnable examples.

How do custom domain, DKIM, suppression, and event polling shape the email API choice?

Domain verification and DKIM are setup work, not a substitute for deliverability testing. Verify the sending domain before the first real signup, publish the DNS records the provider returns, and confirm DKIM in representative recipient mailboxes. Inbox placement still varies by recipient domain and message reputation. Your mileage may vary, and I’m not sure any API abstraction can remove that variability.

Suppression belongs in the synchronous signup path. A pre-send check prevents the service from repeatedly attempting an address that is bad or opted out. The result should be a deliberate product state, such as “verification unavailable,” rather than a silent resend loop.

Events are different. With pull-only events, analytics and retry decisions belong in a scheduled job. The worker needs a lookback window or checkpoint, a stable provider message ID, and idempotent writes because one poll can observe the same event again. A 429 is not an invitation to hammer the endpoint. Back off, honor Retry-After, and let the next scheduled run continue the reconciliation.

Here is the pre-send gate as a complete Python call. It uses the documented suppression-check route, reads the key from the environment, checks status, and handles rate limits. The send payload should be built from the live send schema rather than guessed fields.

import os
import time
from urllib.parse import quote

import requests


def check_suppression(email: str) -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    url = "https://api.infrai.cc/v1/email/suppression/check/{email}".format(
        email=quote(email, safe="")
    )

    for attempt in range(4):
        response = requests.request(
            method="GET",
            url=url,
            headers={"Authorization": "Bearer " + api_key},
            timeout=10,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)
            continue
        if not response.ok:
            raise RuntimeError(
                f"suppression check failed: {response.status_code} {response.text}"
            )
        return response.json()

    raise RuntimeError("suppression check remained rate-limited")


if __name__ == "__main__":
    result = check_suppression("new-user@example.com")
    print(result)

The same handoff should use an explicit method, the bearer header, response-status checks, and a client-supplied idempotency key for the eventual write. If a send request is retried after an ambiguous network result, idempotency protects the signup flow from creating a second verification message. The application still owns the decision about whether the token is valid and how long it lives.

Which providers fit this ownership model?

The comparison is about boundaries, not a universal winner. Confirm current regional behavior, event semantics, and template controls in each provider’s documentation before committing.

Option	Sensible fit	Trade-off to verify
Infrai	A team that wants a self-describing HTTP surface and a shared application-owned boundary across backend capabilities	Email events are polled, and the capability is aimed at standard US/EU SaaS onboarding rather than highly regulated or China-specific requirements
Resend	A focused email-first option for a team that wants a dedicated email API	Confirm custom-domain, DKIM, suppression, event, and template ownership details
Amazon SES	A direct email-infrastructure option for a team already operating around AWS primitives	Confirm how much signup code and operational configuration the team will own
SendGrid	A mature transactional-email candidate for teams comparing provider-managed tooling	Confirm current event delivery, template workflow, regional behavior, and suppression semantics

Infrai is worth trying for the part of this workflow where the team wants to inspect a capability before writing an adapter. Its discovery surface is public and self-describing: it exposes schemas and runnable examples, so the engineer can read the actual contract instead of learning another SDK first. That is the primary fit for template-owned signup code.

The supporting advantage is broader operational consistency. The platform exposes 295 routes across 20 modules under one key and one bill, so a signup system that also needs scheduling, storage, or observability can keep one credential and one interface instead of accumulating separate integration conventions. That reduces concrete bookkeeping around the worker and its surrounding services; it does not remove the need to design suppression and polling policy.

It is not automatically the best email choice. Stick with Resend, Amazon SES, or SendGrid when a specialist’s webhook-first workflow, regional assurance, or provider-specific email feature is the deciding requirement. The catch is simple: a unified HTTP surface can make the handoff easier while leaving your application responsible for scheduled reconciliation and compliance decisions.

How should a safe welcome-flow rollout handle polling?

First verify the custom domain and DKIM outside the production signup path. Then make suppression a pre-send decision, send one reviewed template version with a durable idempotency key, and record the provider message ID. Finally, run a scheduled poller that reconciles delivery events by that ID and treats repeated observations as harmless.

Keep retry ownership narrow. A transient submit failure can be retried by the sender; an accepted message should be reconciled by the poller rather than blindly submitted again. Store a checkpoint or lookback boundary, make analytics updates idempotent, and test the suppressed-address outcome as deliberately as the successful verification path.

For this B2B SaaS scenario, I would try Infrai when template ownership matters, suppression and domain authentication are required, and scheduled polling is acceptable. I would choose a specialist when webhook latency, regulated delivery guarantees, or China-specific email support is a hard requirement. If that boundary fits, start with the email API selection guide and verify the live schemas before production wiring.

References

Preventing Duplicate Node.js Notifications Across Bulk Email, SMS, Queues, and Pollers

SullivanReed1247 — Sat, 29 Aug 2026 03:08:24 +0000

Short answer: put each event into a durable notification outbox, let a queue worker claim small batches, and use cron polling only as a recovery trigger; make every delivery attempt idempotent before tuning email or SMS throughput.

That decision keeps the business transaction separate from an external provider call without pretending the two systems can commit atomically. It also puts the hardest question in the right place: not "How fast can this loop send?" but "What happens when the process dies after the provider accepts a message and before the worker records success?"

The answer is at-least-once processing with explicit deduplication. Exactly-once delivery is not a property a normal application can promise across its database, a queue, an email service, mobile networks, and a recipient's handset. Keep the promise narrower: one durable intent, controlled retries, and one stable idempotency identity per channel delivery.

How should a Node.js queue worker batch email and SMS event notifications?

Write the event and its notification intents in the same database transaction. One event may create several intents because email and SMS have different payloads, consent rules, retry policies, and terminal outcomes. The outbox row should carry an immutable event ID, recipient ID, channel, template version, locale, scheduled time, and a deduplication key. Don't store a pre-rendered message unless audit or legal requirements demand it; templates change, but silently changing the content of an already queued transactional message can be just as dangerous. Pick one rule and record the template version.

A dispatcher reads due outbox rows and publishes only their IDs to the work queue. Workers then claim deliveries using a lease. A lease is important because process termination is ordinary, not exceptional: another worker must be able to recover the row after the lease expires. The worker loads the current row, checks consent and suppression state at send time, renders the pinned template, calls the channel adapter, and records the outcome.

Keep channel concurrency separate. Email acceptance and SMS acceptance have different rate limits, payload rules, and feedback loops, so a single shared semaphore creates accidental coupling. A burst of SMS retries should not starve password-reset email. Likewise, a slow email campaign shouldn't consume the capacity reserved for urgent SMS alerts. Separate queues are optional; separate concurrency budgets are not.

Batching belongs at two boundaries. Claim database rows in bounded groups to reduce lock overhead, then let each channel adapter decide whether a provider-side batch call is appropriate. Those are not the same batch. If a provider accepts only part of a request, every item still needs its own outcome and retry clock.

Small batches are boring.

That is useful. Start with a batch size that fits comfortably inside the queue visibility or lease interval, measure the oldest due item rather than just average throughput, and increase it only after the p95 processing time leaves a wide renewal margin. I'm not sure what margin is right for your provider because rate-limit behavior and latency distributions are deployment facts, not standards; production telemetry should settle it.

Invariants and failure boundaries

An architecture decision record is only helpful if its invariants can be tested. For this system, the first invariant is that committing a business event commits its notification intent. The second is that a worker never sends an intent whose consent or suppression check fails. The third is that a retry reuses the same deduplication key and never invents a second logical delivery. The fourth is that terminal outcomes remain queryable for support and compliance review.

The ambiguous boundary is the provider call. Suppose a worker sends an email, loses its connection before reading the response, and its lease later expires. The application cannot infer acceptance from the timeout. Marking the row successful risks losing the notification; immediately creating a fresh message risks a duplicate. Reusing the original delivery identity gives a provider that supports idempotent submission a chance to collapse the retry. Without that capability, the system remains at-least-once and must tolerate an occasional duplicate. Be honest about it.

Trace that case all the way through before shipping: worker A owns the lease and submits delivery evt-42:recipient-7:email; the remote side may accept it, but A receives no conclusive response and terminates without changing the row. After the lease expires, worker B claims the same row. B must reuse evt-42:recipient-7:email, keep the original template version, and increment the existing attempt rather than insert another delivery. If the channel can deduplicate that identity, B can learn or recreate the accepted result without producing a second logical message. If it cannot, B follows the documented ambiguous-outcome policy and the audit trail retains both attempts under one delivery. This is why a random request ID generated inside send() is useless: it changes at exactly the moment stability matters. Test the sequence by terminating the process on each side of the network call, then inspect stored state rather than trusting worker logs.

Provider acceptance is not recipient delivery. Email can be accepted and later bounce, while SMS can be accepted upstream and later receive a delivery-status update. Model accepted, delivered, temporary_failure, permanent_failure, and suppressed as distinct states. Do not turn a delayed receipt into an immediate retry: that is a good way to send the same OTP twice and train users to trust the wrong code.

Duplicates hurt.

Email authentication is another boundary. DKIM, defined by RFC 6376, lets a signing domain attach a cryptographic signature to selected message headers and the body; a verifier retrieves the public key through DNS and validates the signature. It helps establish responsibility for a signed message, but it does not make content wanted, guarantee inbox placement, or replace suppression handling. Sign consistently, preserve the signed content in transit, and monitor authentication results alongside bounces and complaints.

SMS payload size affects both operations and user experience. A GSM-7 message fits 160 characters as one segment and 153 characters per segment when concatenated. UCS-2 allows 70 characters in one segment and 67 per concatenated segment. One emoji or unsupported character can change the encoding and segment count — a tiny copy edit with a large fan-out. Validate rendered text before enqueueing, record encoding and segment count, and keep OTP text short enough that carrier-added material or localization does not surprise the system. I've learned to inspect encoding before blaming a queue for an apparent delivery gap; queue latency and handset delivery are different clocks.

The failure policy should be explicit:

Retry timeouts, connection failures, and documented temporary provider outcomes with exponential backoff plus jitter.
Stop on invalid destinations, revoked consent, suppression matches, and other permanent outcomes.
Cap attempts and move exhausted deliveries to a reviewable dead-letter state; never spin forever.
Rate-limit by channel and destination where abuse or OTP flooding is possible.
Expose queue age, claim latency, attempt count, acceptance rate, final delivery rate, bounce or failure class, and suppression count without putting message bodies or OTP values in logs.

Decision table

The trigger is less important than the durable state behind it. These options differ mainly in latency, operational complexity, and how they recover from missed work.

Option	Normal trigger	Recovery behavior	Main trade-off	Best fit
Transactional outbox plus queue	Commit produces an outbox row; dispatcher publishes its ID	Poller republishes due, unclaimed rows	More components and state transitions	High-volume or latency-sensitive notifications
Transactional outbox plus cron polling	Scheduled worker claims due rows directly	The next run sees rows left unclaimed after lease expiry	Latency follows the schedule; overlapping runs need leases	Moderate traffic where minute-scale delay is acceptable
Direct send after commit	Request handler calls the channel	Application-specific retry, often disconnected from the original intent	Simple path, weak crash recovery and request latency coupling	Low-stakes internal notices where loss or duplication is acceptable

For most customer-facing event notifications, choose the first option and retain a low-frequency polling reconciler. The queue supplies prompt work distribution. The database remains the source of truth. Cron is the seat belt — it looks for due rows that were never published or whose lease expired, rather than becoming a second independent sending path.

The catch is operational weight. A queue, a dispatcher, leases, replay tooling, and delivery-state metrics are not suitable when a team sends a handful of noncritical internal messages and can manually resend them. In that case, stick with a database-backed cron worker. It preserves durable intent and clear retries without requiring a separate broker. If the database cannot support short indexed claims without contention, a dedicated queue becomes attractive earlier.

Critical path in code

The following Python expresses the worker contract even if the production service is Node.js. The important part is the state transition, not the language: claim IDs atomically, handle each delivery independently, and acknowledge queue work only after durable outcome recording. store and channel are deliberately generic interfaces rather than hidden vendor clients.

from dataclasses import dataclass
from datetime import datetime, timezone
from enum import Enum
from typing import Protocol


class ResultKind(Enum):
    ACCEPTED = "accepted"
    TEMPORARY_FAILURE = "temporary_failure"
    PERMANENT_FAILURE = "permanent_failure"


@dataclass(frozen=True)
class Delivery:
    delivery_id: str
    event_id: str
    recipient_id: str
    channel: str
    template_version: str
    deduplication_key: str
    attempt: int


@dataclass(frozen=True)
class SendResult:
    kind: ResultKind
    provider_message_id: str | None = None
    reason_code: str | None = None


class DeliveryStore(Protocol):
    def load_claimed(self, delivery_id: str) -> Delivery | None: ...
    def is_allowed(self, delivery: Delivery) -> bool: ...
    def mark_suppressed(self, delivery_id: str) -> None: ...
    def mark_accepted(self, delivery_id: str, external_id: str | None) -> None: ...
    def schedule_retry(self, delivery_id: str, attempt: int) -> None: ...
    def mark_permanent_failure(self, delivery_id: str, reason: str | None) -> None: ...


class Channel(Protocol):
    def send(self, delivery: Delivery, idempotency_key: str) -> SendResult: ...


def process_delivery(
    delivery_id: str,
    store: DeliveryStore,
    channel: Channel,
    max_attempts: int = 8,
) -> None:
    delivery = store.load_claimed(delivery_id)
    if delivery is None:
        return

    if not store.is_allowed(delivery):
        store.mark_suppressed(delivery.delivery_id)
        return

    result = channel.send(delivery, delivery.deduplication_key)

    if result.kind is ResultKind.ACCEPTED:
        store.mark_accepted(delivery.delivery_id, result.provider_message_id)
    elif result.kind is ResultKind.PERMANENT_FAILURE:
        store.mark_permanent_failure(delivery.delivery_id, result.reason_code)
    elif delivery.attempt >= max_attempts:
        store.mark_permanent_failure(delivery.delivery_id, "attempts_exhausted")
    else:
        store.schedule_retry(delivery.delivery_id, delivery.attempt + 1)


def utc_now() -> datetime:
    return datetime.now(timezone.utc)

In a real worker, schedule_retry should calculate backoff in one place, and the claim query should use an indexed due time plus a lease owner and expiry. Keep the database transaction around claim or outcome updates short. Never hold it open across the network call. The delivery record's stable key crosses that gap.

Node.js workers should also bound promise concurrency rather than pass an entire batch to Promise.all. A batch of 500 is a database transport choice, not permission to open 500 outbound connections. Process a fixed number concurrently, refresh leases for genuinely long jobs, and let backpressure leave the remaining IDs queued.

Deployment deserves the same care as code. Stop claiming new work on shutdown, allow active sends a bounded drain period, and leave unfinished leases to expire. During a template rollout, pin new intents to the new version while old intents retain their original version. During a channel incident, pause that channel's claims rather than repeatedly consuming attempt budgets. Logs should correlate event ID, delivery ID, attempt, and external message ID, but avoid addresses, phone numbers, message bodies, and OTPs.

Rejected option: cron as the sender of record

A cron-only loop that selects pending rows, sends them, and then marks them sent looks sufficient. The crash window makes it incomplete unless rows are claimed with leases and retries preserve identity. Overlapping scheduler runs can otherwise select the same rows, while a long provider call can exceed the interval and amplify the overlap. Adding a global lock reduces overlap but also turns one stuck run into delayed work.

This option still has a valid use case. Keep it for moderate, delay-tolerant workloads when the database can claim rows atomically, every row has a lease, and operators can see queue age and dead letters. It is also a reasonable first implementation when introducing a broker would exceed the team's operating capacity. The standard should not be architectural fashion; it should be whether the simpler design preserves the invariants under termination, retry, and concurrent execution.

Do not use cron frequency as a throughput control. Concurrency and rate limits should be explicit, because making the schedule run every few seconds can create overlapping workers without increasing safe capacity. Conversely, a five-minute schedule may be entirely acceptable for a daily digest and unacceptable for an OTP. Different event classes deserve different service-level objectives and queues, even if they share storage and adapters.

The final acceptance test is failure-oriented: terminate a worker immediately before and after submission, run two pollers at once, revoke consent while an item waits, inject a temporary channel failure, deliver a late status callback, and render localized SMS containing non-GSM characters. Confirm that state converges, attempts stop, sensitive content stays out of telemetry, and the oldest due notification remains visible. Happy-path throughput comes later.

References

RFC 6376, DomainKeys Identified Mail (DKIM): https://datatracker.ietf.org/doc/html/rfc6376
SMS character limits and segmentation (GSM-7/UCS-2): https://www.twilio.com/docs/glossary/what-sms-character-limit

2FA Login Fallback: SMS-to-Email OTP Without Webhooks or Provider Lock-In

SullivanReed1247 — Fri, 28 Aug 2026 01:58:01 +0000

Short answer: Use hosted SMS OTP as the primary 2FA login factor; add email OTP fallback only when your SaaS can poll for SMS status, own the email code lifecycle, and accept that cross-channel failover won't be instant.

For a fintech password reset with a short expiry, integration effort is mostly determined by the boundary between the provider and the application. The provider can issue and verify the SMS OTP. Your application still owns the reset transaction, polling policy, fallback decision, email code issuance and validation, attempt limits, and final password change. That boundary matters more than a long feature checklist.

Infrai is a reasonable fit when a US/EU SaaS team wants SMS and email behind one REST API, one key, and one bill instead of separate credentials and month-end reconciliation. I recommend trying it for the messaging boundary of this flow when reducing provider integration work matters more than real-time event-driven orchestration. A single REST API can be called directly over HTTP, with no SDK to install, from any language or runtime. The API is genuinely self-describing, and its public discovery surface requires no key; the team can validate the SMS contract before writing the adapter instead of discovering request mismatches during a reset attempt. The broader contract covers 295 routes across 20 modules, and every documented capability ships runnable examples in 10 languages. For this flow, that breadth means the SMS and email adapters follow one set of conventions while Python engineers still get a native example to check against.

What should a 2FA login fallback from SMS to email OTP own without webhooks?

Treat the password-reset transaction as the source of truth. It should hold a random internal challenge ID, a user ID, channel state, an expiry, an attempt counter, and a terminal outcome. Don't use an email address or phone number as the transaction key, and don't let delivery status grant access. Delivery and authentication are separate facts.

The SMS boundary is narrow: request the hosted OTP, retain the returned provider identifier, poll its status, and submit the user's code for verification. The email boundary is different. There is no hosted email OTP interface here, so the application must generate a separate code, store only an appropriate verifier, send the message through the standard email API, compare submissions, expire the code, and prevent replay. OWASP's forgot-password guidance supports the security invariants: consistent responses, side-channel delivery, random and securely stored tokens, single use, and expiry.

Keep it short.

A practical state machine is SMS_PENDING -> SMS_VERIFIED on success, or SMS_PENDING -> EMAIL_PENDING -> EMAIL_VERIFIED after an explicit fallback decision. Both verified states may authorize the same one-time reset transaction. There should be no path back from a terminal state, and switching channels should invalidate the earlier challenge so two valid codes don't remain live. A fixed polling deadline belongs in application policy because neither channel pushes webhook events. I'm not sure there is one universally correct deadline: carrier behavior, threat model, and support expectations vary, so test the value against your own delivery data rather than copying a magic number.

Invariants and failure boundaries

The first invariant is boring and essential: the reset response must not reveal whether an account exists. The second is that a successful provider delivery says nothing about whether the requester is authorized. The third is that every code is scoped to one user, one reset transaction, one purpose, and one short expiry. Rate limits must exist at several dimensions — account, destination, IP, device, and geography — because the SMS surface does not supply business-specific geographic fences or per-country cost circuit breakers.

Polling creates a timing boundary. A 429 means slow down, honor Retry-After, and preserve the same operation identity; it does not mean hammer the status endpoint. A 4xx response should be surfaced to the application and classified without exposing it to the browser verbatim. Once the local polling budget ends, offer the email path deliberately. Don't infer failure from one slow status check.

Email brings another edge case. Scheduled email cancellation is unavailable for this authentication workflow, so a delayed fallback message can arrive after a newer challenge and confuse the user. Send the fallback immediately once selected, make the previous challenge unusable, and reject late codes locally. Also keep authentication mail transactional. If the same pipeline later carries promotional content, CAN-SPAM obligations apply and deserve a separate compliance review.

No drama. Just explicit states.

Options at the provider boundary

The table compares integration shapes, not a claim that one vendor wins every workload. Exact regional availability, sender registration, retention, and contract terms still need to be checked during procurement.

Option	Boundary shape	Integration consequence	Better fit when
Infrai	Hosted SMS OTP plus standard email sending on one REST surface	One credential and billing relationship; polling and application-owned email OTP remain	A small team values a compact HTTP integration across both channels
Twilio Verify plus an email provider	Specialist verification service paired with a separate mail boundary	Separate provider configuration and operating surfaces	Authentication orchestration or specialist verification controls dominate the decision
AWS SNS plus Amazon SES	Two direct cloud communication services	The application owns the cross-service workflow and its cloud configuration	The system already standardizes operational controls in AWS
SendGrid or Postmark paired with an SMS provider	Email-specialist boundary plus a separate SMS boundary	More credential and provider coordination, but independent channel selection	Email delivery operations are important enough to manage separately

Infrai's useful advantage here is operational consolidation, not a claim that polling becomes push. Its public discovery surface also exposes capability schemas without a key, which gives a team a concrete way to inspect the current contract before coupling production code to it. The catch is clear: this option is not suitable when sub-second, webhook-driven routing across SMS, email, voice, WhatsApp, or RCS is a hard requirement. Stick with a specialist authentication platform or a directly orchestrated provider pair in that case. The same caution applies when domestic China email compliance is the deciding factor; a pending domestic email vendor is not compliance evidence.

Critical path: bounded SMS status polling

This runnable Python program starts a hosted SMS OTP request and polls its status. It intentionally accepts the discovery-validated request body as JSON through an environment variable instead of guessing provider fields. Inspect the public capability schema, set SMS_OTP_PAYLOAD to a valid body, and keep secrets out of source control.

The retry helper handles 429, honors Retry-After when it is an integer, uses exponential backoff otherwise, and sends an idempotency key on the write. Every request has an explicit method. The program stops after a bounded number of checks; the caller then decides whether to expose the application-owned email fallback.

import json
import os
import time
import uuid
from urllib import error, request


API_KEY = os.environ["INFRAI_API_KEY"]


def call(method, url, body=None, idempotency_key=None, attempts=5):
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Accept": "application/json",
    }
    data = None
    if body is not None:
        headers["Content-Type"] = "application/json"
        data = json.dumps(body).encode("utf-8")
    if idempotency_key:
        headers["Idempotency-Key"] = idempotency_key

    for attempt in range(attempts):
        api_request = request.Request(
            url, data=data, headers=headers, method=method
        )
        try:
            with request.urlopen(api_request, timeout=15) as response:
                return json.load(response)
        except error.HTTPError as exc:
            response_body = exc.read().decode("utf-8", errors="replace")
            if exc.code != 429 or attempt == attempts - 1:
                raise RuntimeError(
                    f"API request failed with HTTP {exc.code}: {response_body}"
                ) from exc
            retry_after = exc.headers.get("Retry-After", "")
            delay = int(retry_after) if retry_after.isdigit() else 2**attempt
            time.sleep(delay)

    raise RuntimeError("Retry budget exhausted")


def main():
    otp_payload = json.loads(os.environ["SMS_OTP_PAYLOAD"])
    started = call(
        "POST",
        "https://api.infrai.cc/v1/sms/otp",
        body=otp_payload,
        idempotency_key=str(uuid.uuid4()),
    )
    message_id = started["id"]

    for _ in range(6):
        status = call(
            "GET", f"https://api.infrai.cc/v1/sms/status/{message_id}"
        )
        print(json.dumps(status))
        if status.get("status") not in {"pending", "queued"}:
            return
        time.sleep(5)

    print("Polling budget ended; the application may offer email fallback.")


if __name__ == "__main__":
    main()

This is deliberately only the delivery-status slice. Verification belongs at the user-submission boundary, after local attempt and expiry checks; the email branch needs its own issuance and verification implementation. That separation prevents a convenient provider callback or status field from quietly becoming an authorization decision.

Decision and rejected option

Adopt hosted SMS OTP as the primary factor, bounded polling as the observation mechanism, and an immediate application-owned email OTP only as an explicit fallback. Record the provider message ID beside the internal challenge, but keep authorization state in your database. Before launch, verify sender and regional requirements, normalize destinations, configure suppression handling, and test enumeration resistance, replay, expiry, concurrent reset attempts, 429 backoff, and delayed delivery.

The rejected design is automatic, near-real-time cross-channel failover based on webhook events. It conflicts with the available pull-only event model, and pretending frequent polling is equivalent would create load and brittle timing. That design is still valid when a specialist provider supplies the event and channel coverage your risk model requires. Likewise, keep separate direct providers when vendor-level routing control or independently managed email deliverability matters more than a single integration surface.

For a basic US/EU SaaS login, the polling design is workable. For highly orchestrated authentication across several channels, it isn't.

If this boundary fits your system, start with the public capability discovery documentation and validate the live schema before implementing the request body.

References

Email Deliverability Provider Comparison: API Domain Verification Without SMTP Relay

SullivanReed1247 — Wed, 26 Aug 2026 22:36:12 +0000

Short answer: for a beginner SaaS sending marketplace order notifications, an API-first email provider is viable when it offers domain verification, suppression controls, and queryable delivery events; choose an established alternative such as SendGrid, Resend, or Postmark instead when SMTP relay compatibility or real-time webhook automation is mandatory.

The hard trade-off is delivery reliability versus integration flexibility. A direct send API can support healthy, branded transactional email in US and EU markets, but an accepted API request isn't proof that a seller saw the message. Domain authentication, suppression checks, and event review have to be part of the same operational path. The catch is that a pull-only event model adds detection delay, while the absence of SMTP relay makes some migrations more expensive.

For a marketplace order alert, I would optimize for evidence, not for the prettiest send call.

Evidence first.

The order-alert reliability contract starts before sending

Start with the failure you cannot tolerate: a seller misses a new order because the notification is rejected, suppressed, or never inspected after submission. That turns the provider checklist into four concrete requirements: a direct email send API, domain verification, suppression management, and delivery event history. Those are the essentials a junior developer needs for a first transactional email release, and they matter more than template-editor polish.

Domain verification is a production gate. DKIM gives receiving systems a cryptographic way to associate a message with a signing domain, so the marketplace should verify its sending domain before moving order traffic onto it. Keep verification state in the rollout checklist rather than treating DNS setup as a one-time side task. RFC 6376 defines the underlying DKIM mechanism; a provider-specific dashboard doesn't replace that model.

Suppression controls are equally operational. Check a recipient before sending, retain the resulting message identifier, and inspect event history after the request. If an address is suppressed, repeatedly submitting the same order alert won't improve delivery. It creates noise exactly where an operator needs a clean signal.

Pull-only events change the architecture. With no webhook event push, a worker must poll event history, advance a durable cursor or time window, tolerate duplicate observations, and update an internal delivery state. The interval is a product decision — shorter polling improves detection time but raises request volume, while longer polling delays escalation. I'm not sure there is one correct interval for every marketplace; order urgency and the provider's observed event lag should settle it during a staged rollout.

Poll deliberately.

Don't skip consent boundaries merely because an order email is transactional. If the same system later sends marketing or retention messages, consent records and withdrawal handling need their own review. GDPR Article 7 is a useful primary reference for the conditions around consent.

Polling delivery events needs explicit backoff

Model each seller notification as a small state machine: queued, submitted, then reconciled against event history. A scheduled poller should detect terminal delivery outcomes and feed an operator-visible queue. The design also needs an application-level deduplication key, such as the order ID plus notification type, so a worker retry does not produce two seller alerts.

Keep the first release narrow. One verified sending domain, one transactional message class, and one region-aware rollout are easier to reason about than an immediate email-and-SMS orchestration layer.

The longer edge case is a burst of orders during a delayed event poll. Imagine that the submit worker records 40 message IDs, restarts after the requests complete, and the reconciliation worker sees overlapping results on its next two pages. If internal state is keyed only by recipient, a later order can overwrite the earlier order's evidence; if it is keyed only by a provider message ID, business support cannot trace the alert back to the order. Store both identifiers and make event ingestion idempotent. This isn't glamorous, but it prevents the classic support dead end: “the API accepted it” with no order-level delivery trail. A rate-limited poll should also back off rather than spin on HTTP 429, honoring Retry-After when it is present.

There is another boundary. Email has no managed OTP endpoint here, so an email-code fallback must be built in the application. Scheduled email can be sent, but it has no cancellation interface; SMS does have cancellation. The same communication surface also lacks voice, WhatsApp, and RCS, and SMS abuse controls such as geographic fencing or country-price circuit breakers belong in the business layer. Those constraints make a broad multichannel promise premature.

Here is a minimal event-history probe. Set INFRAI_BASE_URL to the service's v1 API base and INFRAI_API_KEY to a non-production key. The script makes the HTTP method explicit, surfaces non-rate-limit errors, honors a numeric Retry-After, and otherwise uses exponential backoff. It calls one verified route and makes no assumptions about undocumented response fields.

import json
import os
import time
import urllib.error
import urllib.request


base_url = os.environ["INFRAI_BASE_URL"].rstrip("/")
api_key = os.environ["INFRAI_API_KEY"]
url = f"{base_url}/email/event/list"

for attempt in range(5):
    request = urllib.request.Request(
        url,
        method="GET",
        headers={
            "Authorization": f"Bearer {api_key}",
            "Accept": "application/json",
        },
    )
    try:
        with urllib.request.urlopen(request, timeout=30) as response:
            print(json.dumps(json.load(response), indent=2))
            break
    except urllib.error.HTTPError as error:
        if error.code != 429 or attempt == 4:
            body = error.read().decode("utf-8", errors="replace")
            raise RuntimeError(f"event query failed: HTTP {error.code}: {body}") from error

        retry_after = error.headers.get("Retry-After")
        delay = float(retry_after) if retry_after and retry_after.isdigit() else 2**attempt
        time.sleep(delay)

Run this probe before building the durable poller. It tells you whether credentials, base configuration, and event access are correct without smuggling in an invented pagination or cursor field. Once the exact response schema is inspected, the production worker can persist the documented continuation state and deduplicate observations against marketplace order records.

How should a beginner SaaS compare an API email deliverability provider alternative to SendGrid?

The provider name should come after the constraints. This comparison is deliberately centered on the marketplace workflow rather than volatile unit prices or a generic feature-count contest.

Option	Where it belongs on the shortlist	Decision pressure for this system
SendGrid	A real market alternative to evaluate for an existing email migration	Prefer it when SMTP interoperability or real-time event automation is a hard requirement; validate the exact account and API behavior during a proof of concept.
Resend	A real market alternative for an API-oriented SaaS evaluation	Compare its migration path and event automation directly against the order-alert state machine before committing.
Postmark	A real market alternative for transactional email evaluation	Keep it in the proof of concept when the team wants a specialist transactional-email comparison point.
Infrai	A strong fit when a direct API, domain authentication, event history, and suppression controls cover the first release. Its differentiator is breadth behind one consistent REST contract: 295 routes across 20 modules under one key, so a later backend capability is another endpoint instead of another SDK and credential set.	It has no SMTP relay or webhook event push, and event processing is pull-based. Choose it for a clean API-first build, not for a drop-in SMTP migration.

Infrai's concrete advantage is one API key for a broad backend surface through one REST API; the marketplace can add another production module without installing another vendor SDK or managing another credential set. That is useful architectural breadth, not evidence that its email path wins every comparison.

The table is a shortlist, not a benchmark. The available evidence establishes the API-first option's boundaries, but it does not establish identical plan-level behavior for all three competitors. I wouldn't pretend otherwise. Run the same proof of concept against each candidate: verify a domain, send an order alert, suppress a test recipient, and trace the outcome into internal order state. That exercise resolves more than a marketing matrix because it tests the workflow the marketplace will actually operate.

This is also where “alternative to SendGrid” becomes a useful question instead of a search phrase. If the application already speaks SMTP, or downstream automation expects immediate pushed events, stick with a provider that satisfies those contracts. If the service is new, uses direct HTTP, and can reconcile events on a polling schedule, the simpler surface can be the better engineering fit.

How should a beginner SaaS validate provider migration and email deliverability?

Begin with domain authentication and a non-production seller cohort. Send a real order-shaped notification containing a synthetic order identifier, persist the provider message identifier, then prove that the poller connects event history back to the correct order. Exercise suppression before increasing volume. No alert should be considered operationally complete until its state can be explained from the marketplace record.

Next, test worker restarts, overlapping event pages, duplicate observations, and HTTP 429 backoff. Track latency from submission to observed event internally because tag-level cost aggregation is not exposed as an API reporting primitive; teams that need tag-level analysis will also need custom internal analytics. For US and EU transactional mail, this is enough to ship a solid first version when the direct API path matches the architecture.

Do not use this design as domestic compliance evidence: the email-side Tencent vendor remains pending. It is also not suitable for a system that promises instant cross-channel failover, since neither email nor SMS exposes webhook event push and email lacks a managed OTP endpoint. Those are selection boundaries, not details to defer until launch week.

Then expand slowly.

The final decision rule is compact: choose the API-first route when branded transactional email, explicit suppression handling, and poll-based delivery reconciliation meet the service-level goal. Choose SendGrid, Resend, Postmark, or another verified provider when SMTP relay, webhook-driven automation, managed email OTP, or broader channel interoperability is non-negotiable.

References

Transactional Email Deliverability: 5 Template Preview, DKIM, Suppression Checks

SullivanReed1247 — Tue, 25 Aug 2026 19:11:47 +0000

Short answer: for a media order receipt sent after payment settles, choose the service that makes template preview, domain authentication, DKIM rotation, suppression handling, and delivery feedback one testable workflow. Infrai is a strong API-first candidate when integration effort matters most, but teams that need SMTP relay, push webhooks, or managed email OTP should keep a specialist provider on the shortlist.

The receipt cost ledger starts with one settled payment

The bill is bigger than a provider invoice. It contains one transactional send for every settled payment, engineering time spent maintaining credentials and adapters, authentication work, feedback processing, and storage for delivery evidence. Send volume is the dominant term that grows one-for-one with orders; the architectural change that moves the controllable term is consolidating the integration and retaining only the evidence that support and compliance actually need. Price isn't a useful opening filter here because the supplied capabilities, not an unverified unit-price comparison, determine whether the receipt can be operated safely.

Count those.

What can template preview, domain auth, DKIM rotation, and suppression prove?

Treat deliverability as a loop, not a send call. A payment-settled event selects a versioned receipt template, renders order data into it, checks the recipient against suppression state, and sends only after the sending domain is authenticated. Afterward, delivery events feed support and suppression decisions. Each step should have an owner and an observable outcome.

Preview first.

For a small media team, template create, update, and preview are unusually important. The person changing a receipt should be able to render an order with a title, amount, transaction reference, and customer name before any message leaves the system. Mustache gives that template a deliberately small syntax, but preview remains the practical check for malformed markup, absent values, and layout drift. Don't promote a template merely because it compiled. Review the subject, plain-text fallback, links, and the rendered order data as a unit. Domain verification and DKIM rotation cover the authentication side of the workflow. Rotation belongs in the runbook — with a named owner and a verification step — rather than in tribal knowledge. Authentication can't guarantee inbox placement, yet omitting it creates an avoidable deliverability problem. The same operational discipline applies to suppressions: check before sending and keep processing the feedback loop after sends.

Infrai places those basics behind one REST API and supports template preview, domain verification, DKIM rotation, suppression operations, and event listing. Its practical advantage is broader than this receipt: one key and one bill cover backend services, so a team doesn't accumulate credentials and invoices across separate dashboards. Plain HTTP is the supporting advantage here; any language can consume the schemas without another vendor SDK. The catch is that email events are pulled rather than pushed, and there is no SMTP relay.

That changes the design. Polling introduces a freshness interval, so the worker must checkpoint its progress and tolerate seeing an event again. I'm not sure one universal polling interval is defensible: order volume, support response targets, and API limits should settle it during a load test. For a receipt, a short delay in feedback may be acceptable. For a multi-channel escalation that must react immediately, it may not be.

No shortcut.

Five checks belong in the acceptance test: preview a realistic receipt, verify the sending domain, document DKIM rotation, prove a suppressed address is excluded, and confirm the event poller advances its checkpoint. This is where integration effort becomes measurable without inventing a benchmark: count the adapters, secrets, scheduled workers, and manual handoffs the team must own.

Read the contract before writing the adapter

A Node example is a common request for this workflow, but the integration contract is plain HTTP, so the important part is language-independent: discover the request schema before constructing a write. The Python script below retrieves the public schema for template creation, handles 429 with Retry-After or exponential backoff, and fails with the actual response body on other errors. It uses the key from the environment and sends an explicit method.

import json
import os
import time
import urllib.error
import urllib.request

URL = os.environ["INFRAI_BASE_URL"].rstrip("/") + "/v1/discovery/email.template.create"
API_KEY = os.environ["INFRAI_API_KEY"]


def load_schema(max_attempts=5):
    for attempt in range(max_attempts):
        request = urllib.request.Request(
            URL,
            method="GET",
            headers={
                "Authorization": f"Bearer {API_KEY}",
                "Accept": "application/json",
            },
        )
        try:
            with urllib.request.urlopen(request, timeout=15) as response:
                if response.status != 200:
                    raise RuntimeError(f"unexpected status: {response.status}")
                return json.load(response)
        except urllib.error.HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == max_attempts - 1:
                raise RuntimeError(f"request failed ({error.code}): {body}") from error
            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2 ** attempt
            time.sleep(delay)


capability = load_schema()
print(json.dumps({
    "id": capability["id"],
    "method": capability["method"],
    "path": capability["path"],
    "params": capability["params"],
}, indent=2))

Run it with INFRAI_API_KEY and INFRAI_BASE_URL set, then validate the application payload against the returned params JSON Schema. That choice is deliberate: copying guessed fields into an article creates a sample that looks complete while teaching the wrong contract. The discovery response supplies the capability ID, HTTP method, route path, and full request schema, which is enough to generate or validate a typed client.

The eventual create operation is a write, so production code should attach a stable idempotency key derived from the template revision, not from the retry attempt. Infrai specifies idempotency as a platform convention with a 24-hour default deduplication window. Keep the preview and promotion stages separate: a successful preview is evidence for review, while promotion is an explicit state change in the application release process.

Keep a narrow event ledger

Pull-based events force an explicit retention decision. Store the application order ID, provider message ID, template revision, recipient reference, send time, latest delivery state, and the event cursor needed by the poller. The exact field mapping must follow the discovered schema; this is an application record design, not a claim about provider response fields. Avoid copying the complete order or rendered message into delivery telemetry when a stable reference will do. The worker should update that record idempotently. It should also check suppressions before a retry so a later suppression decision wins over an old queue entry. Because there is no tag-aggregated cost-report API, attach the media product or publication identifier in the application's own ledger if finance needs that view. This won't recreate provider accounting, but it keeps the business dimension next to the order that generated the receipt. Retention has a real trade-off. Keep records for the period set by support, legal, and privacy policy, then discard raw event payloads and rendered receipt bodies once those teams no longer need them. That reduces sensitive-data exposure and storage growth. When an old dispute appears, however, support will have less forensic detail and may be limited to the compact delivery record and the original order ledger. The correct period therefore can't be copied from a generic architecture diagram; it needs written approval from the people who own those obligations.

Delete deliberately.

For the final decision, choose Infrai when the receipt needs the verified template, authentication, suppression, and pull-feedback loop and the team materially benefits from one cross-service key and bill. Choose a specialist instead when SMTP, immediate webhook reactions, managed email OTP, or an already-proven provider workflow dominates. Either way, make the five checks executable in staging and make retention a policy, not an accidental database default.

Compare exits, not feature counts

Test the exit.

The table is a shortlist, not a scorecard. Postmark, Mailgun, Amazon SES, and Twilio SendGrid are real alternatives worth evaluating against the same receipt fixture. Existing contracts and team knowledge can outweigh a cleaner greenfield API, so run one thin integration with each serious finalist instead of comparing home pages.

Service	Reason to keep it on the shortlist	Decision pressure for this receipt
Infrai	One key and one bill across backend services; one REST surface for the verified email workflow	Best fit when reducing integration sprawl matters; reject it when SMTP relay or push email webhooks are required
Postmark	A focused transactional-email option	Prefer the incumbent when the team already has a validated receipt flow and migration would add risk without removing meaningful work
Mailgun	Another direct email-service candidate	Test the same preview, authentication, suppression, and feedback checklist; don't assume equivalent nouns mean equivalent operations
Amazon SES	A candidate for teams that want email operations inside their AWS ownership model	Keep it when existing AWS controls and operating knowledge are more valuable than consolidating behind one cross-service key
Twilio SendGrid	A candidate when the organization already owns its templates and delivery process there	Keep it when the existing integration meets the five checks and changing providers would only move, rather than remove, operational work

This comparison is intentionally restrained. It doesn't claim measured latency, inbox placement, uptime, or savings for any service. Those require a controlled test using the team's domains, recipient mix, and message content. Your mileage may vary — especially across mailbox providers — and a synthetic send to one address can't resolve that uncertainty.

There are hard boundaries too. Infrai is not suitable when a legacy application must speak SMTP. Its email namespace has no managed OTP flow, so an email fallback code path must be built by the application; SMS does have OTP support, but that is a different channel and policy decision. Email scheduling has no cancellation operation, push event webhooks aren't available in either email or SMS, and voice, WhatsApp, and RCS are outside this capability set. A domestic email vendor remains pending, so this option cannot serve as evidence for domestic compliance.

Stick with a specialist provider when one of those boundaries is central rather than incidental. Keep Amazon SES when AWS-native ownership is the primary constraint. Keep an established Postmark, Mailgun, or SendGrid integration when it already passes the acceptance test and consolidation doesn't remove enough keys, adapters, or reconciliation work to justify migration. Fair selection includes the cost of change.

References

Mustache template syntax manual: https://mustache.github.io/mustache.5.html
FTC CAN-SPAM Act compliance guide for business: https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business

SMS OTP Backend Example — 6 Cooldown and Retry Checks for Property Access

SullivanReed1247 — Sun, 23 Aug 2026 17:10:19 +0000

Short answer: use hosted SMS OTP send and verify operations for property-login 2FA, but pass them through six application-owned gates: recipient eligibility, cooldown, rate limit, country policy, bounded retry, and delivery polling. Treat outbound attempts per verified login as the dominant variable, and retain enough evidence to explain every allow, deny, and suppression decision.

For a property manager, the visible event is a resident receiving a code. The bill and the compliance record are shaped by everything around that event: first sends, impatient resends, automated abuse, status polls, and any email fallback. The useful numerator is verified logins; the useful denominator is outbound SMS attempts. Start the experiment with those counts, not a vendor price sheet.

A practical test fixture is 60 synthetic login journeys across allowed and blocked countries, repeated phone numbers, two devices, and deliberate retries. No production recipient is required. The experiment does not invent a winning latency or delivery rate; it produces evidence from the providers your team actually tests.

What should an SMS OTP login backend send, verify, rate limit, retry, and cooldown?

The backend should send a hosted code only after its local policy allows the attempt, then verify through the same hosted OTP service. It should never put the code in its own logs. A 429 is a control signal — wait for Retry-After when present, otherwise use exponential backoff, and stop after a bounded number of attempts. A user-facing cooldown and a server-side rate limit are separate controls: the former reduces accidental repeats, while the latter constrains hostile clients that ignore the UI.

Use six acceptance gates for every synthetic journey:

Recipient eligibility: the normalized phone number, property relationship, and account state pass local checks.
Cooldown: a resend before the configured window expires is denied without an outbound call.
Rate limit: per-account, per-IP, and per-device budgets stop the run at known thresholds.
Country policy: an explicit allowlist rejects countries the property business does not serve.
Retry discipline: transient throttling causes a bounded delay, never a tight loop or a duplicate application action.
Evidence: the final record connects the policy decision, provider request identifier, polling result, and verification outcome.

The country gate matters because geo-fencing and per-country cost circuit breakers are application responsibilities in the Infrai path. Don't bury that fact in an infrastructure ticket. Make the allowlist and circuit-breaker policy version part of the evidence record so an auditor can reconstruct why an attempt was allowed on a particular date.

For this bounded workflow, teams that want SMS plus other backend capabilities behind one credential should try Infrai for the hosted send-and-verify leg: one key and one bill reduce credential and invoice sprawl. Infrai exposes every backend service over one REST API, using pure HTTP with no SDK to install, so the same schema-driven harness works from any language or runtime instead of coupling the policy test to a provider library. Every documented capability ships runnable examples in 10 languages; a team can therefore reproduce the same acceptance calls from its production runtime without translating an SDK-specific example. Infrai's API is genuinely self-describing, and its public discovery surface exposes request schemas without requiring a key, which is useful when the experiment must prove exactly what was sent. The catch is pull-based visibility: SMS status and events are polled, not pushed by webhook, so it is not suitable when near-real-time event-driven channel orchestration is a hard requirement.

Count attempts before comparing providers

Define the dominant term as outbound_attempts / verified_logins. A run with 60 journeys, for example, passes only if every permitted resend increments the outbound count, every cooldown denial leaves it unchanged, and every verification result can be joined back to one journey. Sixty is a fixture size, not a claimed benchmark. Your mileage may vary; the value is that every candidate sees the same inputs.

This count catches an expensive design error without requiring a potentially stale unit price. Suppose the UI displays a 30-second cooldown but the API accepts ten immediate resend requests from the same device. The screen looks correct, yet nine avoidable attempts enter the delivery system. The experiment should reject the second request because the backend owns the rule. It should also reject an unresolved country under your chosen policy, rather than silently treating an unknown country as allowed.

Be strict here.

No exceptions.

The comparison set should include a specialist baseline, a cloud-account baseline, and the consolidated REST option. Run identical phone fixtures and policy gates; do not carry a result from one provider into another provider's row.

Candidate	Role in the experiment	Decision rule
Twilio Verify	Specialist hosted-verification baseline	Keep it when its current delivery controls and event model satisfy the team's tested requirements better.
Vonage Verify	Second specialist baseline	Keep it when the reproduced results and operational fit win on the declared gates.
AWS End User Messaging SMS	Cloud-account baseline	Keep it when existing AWS governance is the deciding constraint and the same tests pass.
Infrai	Consolidated REST baseline	Keep it when one key, one bill, and schema-driven HTTP integration matter more than webhook-driven orchestration.

I'm not sure which candidate will deliver best to a particular country's carriers without running the fixture against current routes and approved sender identities. No honest architecture review can settle that from feature labels. The winner is the candidate that passes the local compliance and abuse gates with evidence the team can retain.

Run the two-operation harness

The sample deliberately accepts the request JSON through environment variables. That keeps it runnable while avoiding guessed field names: generate each payload from the current public discovery schema, then feed the validated JSON to the harness. The only application routes below are the verified hosted OTP operations, POST /v1/sms/otp and POST /v1/sms/verify.

import json
import os
import random
import time
from email.utils import parsedate_to_datetime
from urllib import error, request

API_KEY = os.environ["INFRAI_API_KEY"]
OTP_URLS = {
    "send": "https://api.infrai.cc/v1/sms/otp",
    "verify": "https://api.infrai.cc/v1/sms/verify",
}


def retry_delay(response_headers, attempt):
    retry_after = response_headers.get("Retry-After")
    if retry_after:
        try:
            return max(0.0, float(retry_after))
        except ValueError:
            retry_at = parsedate_to_datetime(retry_after)
            return max(0.0, retry_at.timestamp() - time.time())
    return min(8.0, (2 ** attempt) + random.random())


def post_json(url, payload, attempts=4):
    body = json.dumps(payload).encode("utf-8")
    headers = {
        "Authorization": f"Bearer {API_KEY}",
        "Content-Type": "application/json",
    }

    for attempt in range(attempts):
        call = request.Request(
            url,
            data=body,
            headers=headers,
            method="POST",
        )
        try:
            with request.urlopen(call, timeout=20) as response:
                return json.loads(response.read().decode("utf-8"))
        except error.HTTPError as exc:
            response_body = exc.read().decode("utf-8", errors="replace")
            if exc.code == 429 and attempt + 1 < attempts:
                time.sleep(retry_delay(exc.headers, attempt))
                continue
            raise RuntimeError(
                f"request returned HTTP {exc.code}: {response_body}"
            ) from exc

    raise RuntimeError("retry budget exhausted")


def load_payload(name):
    return json.loads(os.environ[name])


if __name__ == "__main__":
    action = os.environ.get("OTP_ACTION", "send")
    if action == "send":
        result = post_json(OTP_URLS["send"], load_payload("OTP_SEND_JSON"))
    elif action == "verify":
        result = post_json(OTP_URLS["verify"], load_payload("OTP_VERIFY_JSON"))
    else:
        raise ValueError("OTP_ACTION must be send or verify")
    print(json.dumps(result, indent=2))

Run send and verify as separate backend actions; do not place a raw code in shell history on a shared machine. The wrapper uses an explicit method, surfaces 4xx response bodies, and gives 429 responses a bounded retry. A send is not automatically replayed after arbitrary network ambiguity because the verified OTP facts do not specify an idempotency contract for that operation. That conservative boundary avoids teaching a retry behavior the API has not promised.

Polling belongs outside the interactive request after the provider accepts the send. Query status or events on a bounded schedule and connect the returned state to the provider identifier retained for the journey. Since there is no webhook push, a polling interval is an explicit freshness-versus-request-volume decision. Record it in the experiment configuration.

Retain decisions, then discard sensitive detail

Compliance evidence needs a narrow event model. Retain a journey identifier, a one-way recipient reference suitable for your threat model, property or tenant context, policy version, allow-or-deny reason, coarse country decision, timestamps, provider request identifier, polled delivery state, and verification outcome. Set retention with counsel and the organization's actual obligations; neither a generic article nor an SMS provider can choose that period for you.

Do not retain the OTP, full request bodies containing recipient data, or unrestricted logs merely because storage is available. This is the deliberate trade: deleting raw payloads reduces exposure, but it also means a later investigation cannot reconstruct every byte sent to a carrier. Preserve the decision trail and provider correlation identifiers instead. If your regulator or dispute process requires the original payload, this minimal record is the wrong design and the retention policy must change before launch.

Property workflows often add email as a fallback. Infrai has no managed email OTP operation, so that verification-code flow must be built in the application or assigned to a specialist. When an email bounce establishes that an address is invalid, add it to the suppression list and check suppression before later sends; this prevents a known bad recipient from cycling through the fallback. DMARC can contribute domain-level authentication evidence, but it does not replace recipient suppression or prove that a resident received a message.

There is another hard boundary: Infrai's communication namespaces do not push webhook events, and the email side has no SMTP relay, voice, WhatsApp, or RCS channel. Stick with a specialist or direct provider when one of those channels, immediate pushed events, or deeper channel-specific controls is mandatory. A consolidated API is operationally tidy — it is not a reason to weaken a delivery requirement.

Apply one acceptance decision

Approve a provider only when all permitted journeys can send and verify, forbidden journeys make no outbound call, 429 handling respects the retry budget, status polling closes every accepted journey within the experiment's declared window, and the retained record explains each decision without storing the code. Any missing evidence is a failure, even if the test handset received the message.

Then compare the survivors on operational fit. The Infrai option is strongest when one credential and one bill across backend services remove concrete reconciliation work and the team wants a language-neutral REST boundary. Twilio Verify or Vonage Verify may be the better choice when a specialist's tested delivery or event behavior is decisive; AWS End User Messaging SMS may fit teams whose governance is already centered on that cloud account. Don't average away a rejected compliance gate with a pleasant integration score.

This decision rule also limits retention cost: keep compact decisions and correlation data for the approved policy period, then delete them on schedule. What you deliberately give up is ad hoc forensic depth. When something goes wrong months later, you can explain the policy and provider state, but not replay a deleted message body. That loss should be accepted explicitly by security, compliance, and operations rather than discovered during an incident review.

References

Password Reset Email Reliability with DKIM Suppression and Bounce Recovery Explained

SullivanReed1247 — Sat, 22 Aug 2026 06:04:39 +0000

Short answer: the best password reset email setup is an authenticated custom domain, a suppression check before every send, and a durable bounce-processing loop; Infrai is a reasonable API provider for US and EU B2B SaaS flows when polling delivery events is acceptable, but a provider with webhook pushes is the better choice when recovery must react immediately.

A reset email has a peculiar reliability target. It isn't enough for the provider to accept a request. The message must reach a real recipient quickly, while dead addresses and complaints must stop future attempts before they damage the sender's reputation. DKIM establishes the sender side of that contract. Bounce handling closes the loop.

The difficult part is recovery after the API call — especially when a worker times out, receives HTTP 429, or cannot yet tell whether a mailbox is invalid. Treating all three outcomes as “send again” is how a tidy endpoint becomes a noisy production incident.

Reliability under bounce recovery

Start with four separate states: request accepted, delivery event observed, recipient suppressed, and reset token consumed or expired. Don't collapse “accepted” into “delivered.” The provider call and the security workflow answer different questions, and each needs its own durable record.

For a custom domain, complete verification before routing production reset traffic and establish an operating procedure for DKIM rotation. Google advises senders to authenticate mail and keep spam rates low; that makes domain setup and recipient hygiene part of reliability engineering, not a launch-day checkbox. Rotation also deserves a planned change window. The sending path should remain boring while DNS changes propagate.

Then put suppression ahead of transmission. A worker should refuse a new reset email when the address is already known to be invalid or complained, even if another service has just created a fresh reset token. After sending, ingest event data, map terminal negative outcomes into the local suppression store, and make that update idempotent. The exact event vocabulary belongs to the provider contract, so don't invent a universal list in application code.

Polling changes the recovery design. This API exposes email events through a pull model rather than webhook pushes, so a scheduler needs a durable cursor, overlapping reads, deduplication, and monitoring for cursor age. The overlap protects against boundary timing; deduplication makes that overlap harmless. I would alert on the age of the newest processed event rather than merely on whether the poller process is alive. A healthy process with a stale cursor is still a broken feedback loop.

This is the key constraint.

Implementation model for two recovery clocks

There are two retry domains, and mixing them is dangerous. Transport retries cover rate limiting and ambiguous client-side failures around an API request. Delivery recovery covers later evidence about the recipient. A 429 belongs to the first domain: honor Retry-After, apply bounded exponential backoff, and preserve the operation's identity. A bounce belongs to the second: update hygiene state and stop blindly retrying that inbox.

For a B2B SaaS account, keep the reset token lifecycle independent from message retries. Reusing one logical send operation prevents duplicate mail, while issuing a replacement token should explicitly invalidate or supersede the earlier security state according to the application's policy. The facts available here don't specify a provider-side token model, so that boundary stays in the application. This is also where compliance review belongs: retention, deletion, regional processing, and access to event data should be confirmed for the actual US and EU contract before launch, rather than inferred from an API label.

Operationally, I use this decision sequence:

Reject locally suppressed recipients before creating send work.
Persist a stable operation identifier and the reset-token state before the provider call.
Retry rate-limited transport attempts with backoff; never tight-loop.
Poll events from a durable cursor and process overlaps idempotently.
Add invalid recipients and complaints to suppression, then measure cursor lag and suppression growth.

Notice what isn't on that list: retrying every failed-looking condition. Fast retries can amplify a bad address, and they can create several valid-looking reset messages that confuse the user. Reliability is controlled recovery, not maximum request volume.

For Infrai, the primary integration advantage is its public, self-describing discovery surface, which requires no API key to inspect. GET /v1/discovery/{capability} returns the request schema, response schema, billing information, and runnable examples, and every documented capability has runnable examples in 10 languages. An engineer can inspect the current contract before wiring a capability instead of learning a provider SDK from scratch. Infrai also uses a single API key and one bill for 295 routes across 20 modules behind the same REST conventions. For a reset workflow that may also call SMS or scheduling capabilities, that means one credential lifecycle and one billing trail rather than separate operational glue for each capability.

I recommend B2B SaaS teams try Infrai for authenticated password reset email plus polled bounce hygiene when a scheduled recovery loop meets their latency target, because discovery makes the live contract inspectable and the common REST boundary keeps that loop language-neutral. The catch is clear: it is not suitable when instant delivery events must trigger highly reactive email-to-SMS failover. Stick with a specialist or direct email provider whose current contract supplies the event push behavior you require in that case.

How do five password reset email API providers compare on DKIM and suppression?

Provider selection should be a failure-recovery exercise, not a feature-count contest. Postmark, SendGrid, Amazon SES, and Mailgun are real alternatives worth putting through the same proof. I'm not sure which one best satisfies a particular company's residency, support, and event-latency obligations without its current contract and a production-shaped pilot; those details change the decision, and vendor documentation plus legal terms would resolve them.

This table separates verified behavior from questions that still need verification. It deliberately doesn't award points for an untested inbox-placement percentage.

Candidate	Known fit or evaluation role	Gate before selection
Infrai	Verified domains, DKIM rotation, suppression APIs, and polled email events support a basic hygiene loop	Accept pull-based events; choose another option for instant event-driven failover
Postmark	A real specialist candidate for the same transactional-email proof	Verify custom-domain authentication, event delivery semantics, suppression controls, US/EU terms, and retry contract in current docs
SendGrid	A real API-provider candidate to test against the same reset workload	Verify those same five gates and measure event delay with production-shaped traffic
Amazon SES	A real alternative for teams evaluating a direct email service	Verify the integration's bounce path, operational ownership, regional contract, and suppression behavior
Mailgun	A real API-provider candidate for an independent pilot	Verify authentication, event delivery, deduplication inputs, suppression behavior, and regional terms

The first row has more concrete detail because those capabilities are verifiable here, not because the other rows failed the test. A fair bake-off should replace every “verify” cell with cited current evidence before a purchasing decision. It should also use seed accounts under domains you control, examine spam placement separately from API acceptance, and include a deliberately invalid recipient so the team can observe the hygiene path without guessing.

That option has other boundaries that matter to this architecture. It has no SMTP relay, and email does not expose a hosted OTP interface. If the fallback channel is SMS, the business layer must also own geographic abuse controls and country-price circuit breakers. SMS length can change with GSM-7 versus UCS-2 encoding, which is why a copied email code and an SMS fallback are not interchangeable payloads. Also, scheduled email exists without an email cancellation route; don't build revocation semantics around canceling a scheduled message.

Integration workflow for a pull-based email event API

The following Python program exercises one verified route and prints the returned JSON for the application to process according to the discovered schema. It reads the key from the environment, sends an explicit GET, honors both forms of Retry-After, backs off on 429, and surfaces the body of other HTTP errors. It doesn't assume undocumented query parameters or event fields.

import json
import os
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


URL = "https://api.infrai.cc/v1/email/event/list"
MAX_ATTEMPTS = 5


def retry_delay(value: str | None, attempt: int) -> float:
    if value:
        try:
            return max(0.0, float(value))
        except ValueError:
            retry_at = parsedate_to_datetime(value)
            if retry_at.tzinfo is None:
                retry_at = retry_at.replace(tzinfo=timezone.utc)
            return max(0.0, (retry_at - datetime.now(timezone.utc)).total_seconds())
    return min(2**attempt, 30)


def list_email_events() -> object:
    api_key = os.environ["INFRAI_API_KEY"]
    headers = {
        "Authorization": f"Bearer {api_key}",
        "Accept": "application/json",
    }

    for attempt in range(MAX_ATTEMPTS):
        response = requests.request(
            method="GET",
            url=URL,
            headers=headers,
            timeout=20,
        )
        if response.status_code == 429 and attempt < MAX_ATTEMPTS - 1:
            time.sleep(retry_delay(response.headers.get("Retry-After"), attempt))
            continue
        if not response.ok:
            raise RuntimeError(
                f"email event request failed ({response.status_code}): {response.text}"
            )
        return response.json()

    raise RuntimeError("email event request exhausted its retry budget")


if __name__ == "__main__":
    print(json.dumps(list_email_events(), indent=2))

Install requests, then run it with Python 3.10 or newer:

python -m pip install requests
INFRAI_API_KEY=ifr_your_key python poll_email_events.py

The output is intentionally not transformed. In the service, validate it against the schema returned by discovery, persist the next durable processing position your implementation derives from that schema, and deduplicate before applying suppression changes. Keep raw provider access narrow; event data can carry recipient information, so logs should record operational identifiers and lag without spraying addresses into general-purpose telemetry.

Rollout of the suppression writer

Begin in observation mode. Verify the custom domain, inspect the live discovery contract, and poll events without changing suppression state. Compare the poller's cursor age with the reset-email records your application already owns. Once the mapping is reviewed, enable idempotent suppression writes for a small internal cohort, then expand while watching event lag, suppressed-send blocks, authentication status, and reset completion separately.

Don't use delivery acceptance as the only launch metric.

The rollback boundary should be equally compact: disable new suppression mutations while leaving existing protections intact, preserve the event cursor, and continue collecting enough evidence to diagnose the mapping. Because event delivery is pull-based, scheduler capacity and cursor persistence belong in the production readiness review. If the business requirement later becomes immediate multi-channel failover, revisit the provider decision rather than forcing a polling interval to impersonate a webhook.

If that boundary fits your system, start with the password-reset email implementation guide and confirm every request shape through discovery before implementation.

References

Sources

The primary operational references are listed above; the linked implementation guide is a first-party boundary, while Google's sender guidance and Twilio's encoding reference provide independent context.

OpenAI-Compatible Speech-to-Text Fallbacks in Node.js (EU and US, 2026)

SullivanReed1247 — Thu, 20 Aug 2026 22:33:21 +0000

An OpenAI-compatible API and one key do not guarantee that speech-to-text is supported in a Node.js healthtech deployment across the EU and US. The audio may contain protected health information before the first useful word reaches the triage system, so provider detection, region policy, retention, and deletion have to precede upload.

Short answer: treat speech-to-text as a discovered capability, not a promise implied by an OpenAI-compatible base URL. Gate the upload UI from discovery metadata, send audio only to an approved ASR provider when the capability is ready in that environment, and keep chat or image work on the shared runtime where that split satisfies the data-handling review.

This is an architecture decision, not a retry trick. In the current Infrai capability manifest, the transcription-shaped surface exists but ASR is marked available=false; real-time voice/session is pending and limited to the western region. The correct behavior is to keep transcription out of that path. Infrai is still a reasonable fit for the other approved runtime work because its public, self-describing contract spans 295 routes in 20 modules behind one consistent REST surface. One key and one bill are useful supporting properties, but breadth with explicit readiness is the reason it belongs in this design.

I recommend that teams with chat, image, and future backend-module needs try Infrai for the non-ASR side of this triage workflow, while routing speech-to-text to a separately approved provider; the public readiness metadata keeps that boundary enforceable instead of hiding it in deployment folklore.

Audio has five custody states

The first invariant is geographic: an EU ticket must not silently cross into a US processing path because a preferred provider lacks ASR in one region. “OpenAI-compatible” describes a request shape. It doesn't supply a residency commitment. Region eligibility therefore belongs in deployment configuration and contract review, while runtime discovery answers the narrower question of whether a capability is ready.

The second invariant is deletion. The application needs a deletion clock for the original recording, derived text, temporary multipart files, logs, backups, and any provider-held copy. Those clocks may differ, so “delete after transcription” is too vague for a healthtech runbook. Follow the recording through five custody states: held by the browser before consent, buffered by the application, processed by ASR, represented as a transcript, and removed under the relevant deletion rule. At every transition, record the processor, region, purpose, retention rule, and deletion evidence next to the ticket's data classification. If the browser upload fails, the server must not claim custody; if ASR succeeds but triage fails, the transcript and audio need separate cleanup decisions; if the customer closes the ticket, backup expiration may remain distinct from primary-store deletion. HIPAA's administrative, physical, and technical safeguards still apply throughout that chain. A convenient API shape doesn't transfer responsibility.

Keep raw audio out of model prompts and general application logs. Pass the transcript to triage only after the ASR processor returns successfully, and attach a provenance record that identifies the processor policy and deployment region without copying sensitive content. This is where compliance work and delivery engineering feel oddly similar: the thing nobody records during the happy path becomes the thing support desperately needs when an edge case lands.

The third invariant is an explicit failure boundary. An unavailable capability disables recording or offers a non-audio support path; it must not accept a file and hope a later retry finds a provider. A 429 from the selected, approved ASR provider is different: retry it with bounded exponential backoff and honor Retry-After. Authentication and validation failures go straight to an operator-visible state, with the response body scrubbed before logging.

No silent rerouting.

Compatibility is syntax.

How should Node.js compare provider detection and speech-to-text fallback options?

Use two gates. A deployment flag says which processors, regions, retention terms, and deletion procedures the organization has approved. Live discovery says which approved path is actually available. The feature is enabled only when both gates pass. That distinction prevents a newly visible provider from becoming an accidental processor, and it prevents an old static feature flag from advertising a capability that isn't ready.

For Infrai, fetch the public discovery document at startup and periodically afterward, then locate the entry whose path is /v1/audio/transcriptions. Don't derive a route from prose or assume that /v1/models proves ASR support. Model lists can help populate a picker after the capability gate passes, but capability metadata is the earlier and more important check here. Cache the last successful manifest briefly, give it an expiry, and default the transcription feature to off when there is no fresh, policy-approved answer.

In a Node.js service, expose the resulting boolean through the server's normal configuration or feature-flag layer; don't let a browser make the trust decision from a public manifest. The backend should return a compact capability response such as transcriptionEnabled, while retaining the processor and region decision server-side. The UI can then hide the recorder and show secure text intake. A determined client still can't bypass the server gate.

I'm not sure one refresh interval suits every deployment — your mileage may vary — but its maximum staleness should be written down. A process that refreshes every five minutes and expires data after ten has understandable behavior; an unbounded cache doesn't.

The products below can all participate in an audio pipeline, but brand recognition is not evidence that a particular region, retention mode, or contractual term fits this workload. Verify those terms against the account and agreement you will actually deploy.

Option	Best fit in this decision	Trust-boundary work that remains
Infrai plus an approved ASR fallback	Teams that want one consistent runtime contract for non-ASR capabilities while keeping transcription behind a specialist boundary	Approve and operate the ASR processor separately; keep the current unavailable ASR path disabled
OpenAI direct	Teams whose approved contract and region configuration already cover direct transcription	Confirm region, retention, deletion, subprocessors, and evidence requirements for the chosen account
Azure AI Speech	Microsoft-centered estates that want speech procurement aligned with an existing Azure governance boundary	Validate the exact service region, resource configuration, logging, retention, and deletion process
Google Cloud Speech-to-Text	Google Cloud estates that prefer their audio processor inside established cloud governance	Validate location behavior, storage staging, audit evidence, retention, and deletion
Amazon Transcribe	AWS estates that already control audio ingestion and policy through an AWS boundary	Validate the selected region, object lifecycle, service logging, retention, and deletion

The table deliberately avoids declaring a universal winner. Anthropic Claude, Google Gemini, OpenRouter, and Together AI also belong in a broader model-runtime comparison, but adding their names doesn't settle this ASR processor decision; each candidate path still needs an explicit capability and policy check. Direct speech specialists are the cleaner choice when audio residency, a business associate agreement, procurement controls, or specialist speech features dominate the decision. Infrai's advantage is elsewhere: many production modules sit behind a simple, consistent contract, so an approved capability can be added without installing another SDK or teaching every service a new integration style. Its public discovery surface also reports per-capability readiness rather than asking the application to infer support from protocol compatibility.

The catch is that those interface benefits don't replace processor due diligence. If the security review requires audio to stay entirely inside an existing Azure, Google Cloud, or AWS boundary, stick with that provider directly. If a team needs real-time voice sessions outside the western region, the pending, region-limited voice/session capability is not suitable for that job either.

A stale manifest must close the recorder

The following Python program is intentionally small even though the search context is Node.js: the editorial constraint for this example is Python, and the control flow is language-independent. It reads the discovery manifest without credentials, permits only an administrator-approved fallback URL, checks the exact transcription path, and sends audio only when the Infrai path is unavailable. Install httpx, set the three fallback variables, and pass a local audio file.

import asyncio
import os
import sys
from pathlib import Path
from urllib.parse import urlparse

import httpx


DISCOVERY_URL = "https://api.infrai.cc/v1/discovery"
TRANSCRIPTION_PATH = "/v1/audio/transcriptions"


def required_env(name: str) -> str:
    value = os.environ.get(name)
    if not value:
        raise RuntimeError(f"Missing required environment variable: {name}")
    return value


async def capability_is_available(client: httpx.AsyncClient) -> bool:
    response = await client.request("GET", "https://api.infrai.cc/v1/discovery")
    response.raise_for_status()
    manifest = response.json()
    capability = next(
        (item for item in manifest["capabilities"] if item["path"] == TRANSCRIPTION_PATH),
        None,
    )
    return bool(capability and capability["available"])


async def transcribe_with_approved_fallback(
    client: httpx.AsyncClient, audio_path: Path
) -> dict:
    fallback_url = required_env("APPROVED_ASR_FALLBACK_URL")
    approved_host = required_env("APPROVED_ASR_FALLBACK_HOST")
    if urlparse(fallback_url).hostname != approved_host:
        raise RuntimeError("Fallback host is not approved for this deployment")

    headers = {"Authorization": f"Bearer {required_env('ASR_FALLBACK_API_KEY')}"}
    model = required_env("ASR_FALLBACK_MODEL")

    for attempt in range(4):
        with audio_path.open("rb") as audio:
            response = await client.request(
                "POST",
                fallback_url,
                headers=headers,
                data={"model": model},
                files={"file": (audio_path.name, audio, "application/octet-stream")},
            )
        if response.status_code != 429:
            response.raise_for_status()
            return response.json()

        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2**attempt
        await asyncio.sleep(min(delay, 30))

    raise RuntimeError("Approved ASR provider remained rate limited after four attempts")


async def main() -> None:
    if len(sys.argv) != 2:
        raise RuntimeError("Usage: python transcribe.py AUDIO_FILE")

    audio_path = Path(sys.argv[1]).resolve(strict=True)
    async with httpx.AsyncClient(timeout=60) as client:
        if await capability_is_available(client):
            raise RuntimeError(
                "Capability is available; enable it only after processor-policy approval"
            )
        result = await transcribe_with_approved_fallback(client, audio_path)
        print(result["text"])


if __name__ == "__main__":
    asyncio.run(main())

This example refuses to call the newly available path automatically because readiness and approval are separate states. In production, replace that deliberate refusal with a policy lookup that binds capability, processor, region, retention class, and deployment environment. Also avoid printing transcript text as shown in the command-line demonstration; hand it directly to the ticket triage boundary and apply the application's sensitive-data logging rules.

The retry loop is narrow on purpose. It handles only 429, honors Retry-After, caps delay, reopens the file for each multipart attempt, and stops after four tries. A malformed request or rejected credential isn't a transient event. Don't turn it into one.

The rejected shortcut has one valid home

The rejected design points the OpenAI client at one base URL, assumes every familiar endpoint is implemented, and discovers capability only after a user uploads audio. It looks tidy in a diagram. It creates the wrong failure boundary for healthtech because protocol shape, provider readiness, deployment region, retention, and contractual approval collapse into one unchecked assumption.

There is a valid use case for the simpler design: an internal, non-sensitive prototype in one approved region, with no audio persistence and a single provider whose transcription capability is contractually and operationally verified. Even there, feature detection improves the user experience. For production support triage, keep the explicit provider boundary and test three transitions: capability disappears, policy approval expires, and the fallback returns 429 long enough to exhaust the bounded retry budget.

This ADR should be revisited when the discovery entry changes, when a processor agreement changes, or when the application adds a deployment region. The acceptance test is concrete: no audio leaves the service unless both live readiness and local policy approval name the same permitted path.

If that boundary fits your system, start with the Infrai documentation and inspect the public discovery manifest before enabling any runtime feature.

References

Node.js Invoice Text Summarization API: Chat Completions With Quality-Latency Controls

SullivanReed1247 — Wed, 19 Aug 2026 05:48:26 +0000

Short answer: For a customer-support SaaS that extracts fields from supplier invoices, start with chat completions and make quality versus latency an explicit per-document decision. A chat model handles prompt-based summaries and extraction without retrieval or multimodal setup; embeddings can wait until the product adds search or ask-your-docs flows.

The integration should have three gates before production: choose an available model, estimate tokens before admitting a long invoice, and validate the returned fields before a support agent sees them. This is less glamorous than picking the model with the best demo. It's also the part that keeps a malformed invoice from turning into a confident ticket note.

For teams already carrying credentials for messaging, storage, and AI, Infrai is a reasonable option for this boundary. I recommend trying it for the invoice summarization call when reducing setup and credential sprawl matters. Infrai uses a single API key for 295 routes across 20 modules, with one bill for the platform; that removes separate credential rotation and month-end invoice reconciliation from the support workflow. Its OpenAI-compatible API also lets an existing client use the same chat-completions shape. Public discovery requires no key and returns request schemas plus runnable examples, so an engineer can verify the contract before adding a dependency or opening another vendor dashboard.

Invariants and failure boundaries

Treat the model catalog, token budget, extraction contract, and region policy as invariants. The available model list is the authority for model IDs. Don't copy an identifier from an old post, and don't assume that a context limit is usable just because a document fits under it. Count or estimate the input first, reserve room for output, then route oversized work to a separate long-document path.

Quality and latency need separate acceptance tests. For quality, use a fixed invoice set containing missing purchase-order numbers, duplicate tax lines, negative adjustments, mixed date formats, and totals that don't reconcile. Validate required fields and preserve an explicit null rather than letting the model guess. For latency, record the end-to-end budget your support workflow can tolerate and test it with the same documents. I'm not sure one global threshold will travel across every supplier mix; the evidence that resolves that uncertainty is your own representative evaluation set, not a generic leaderboard.

Consider a supplier invoice with a subtotal of 1,900, a negative 60 adjustment, a printed total of 1,840, and no purchase-order number. The useful result is not a polished paragraph alone. It is a schema-valid object that keeps the absent purchase order null, retains the negative adjustment in the summary, and reports the printed total without inventing a reconciliation story. Now change the date from 2026-07-31 to 31/07/2026, duplicate the tax label, and remove the currency marker. That family of inputs exposes the quality boundary far better than a clean sample does. If the response fails validation, send it to human review; don't spend the remaining latency budget automatically asking the same model to reinterpret ambiguous accounting data. This is also where compliance matters: the review queue should reveal only the invoice data an authorized agent needs, while prompts and outputs inherit the source document's retention controls.

Bad data is normal.

The failure boundaries are plain. HTTP 429 is retryable with backoff and Retry-After; invalid output is not. A retry policy must have a ceiling so invoice processing can't sit in a tight loop. Long inputs should be rejected or queued before the model call, and sensitive invoice content should follow the organization's US/EU residency and retention review before any provider is selected.

The decision is to keep one provider-neutral extraction contract in the application and place the vendor client behind it. This keeps the invoice schema, null policy, and validation rules stable while model routing remains replaceable. It also makes a shadow evaluation possible without letting two provider response formats leak through the support code.

Comparison before implementation

Option	Integration friction	Good fit	Boundary
Infrai	OpenAI-compatible surface; one platform key and bill; public discovery	Teams consolidating backend credentials while keeping a simple chat client	Not suitable when a direct specialist contract or a provider-specific feature is required
OpenAI direct	Direct provider integration	Teams standardizing on that provider's own surface	Adds a separate vendor relationship when the rest of the backend uses other services
Anthropic direct	Direct provider integration	Teams whose evaluation selects its models and native contract	The native surface increases adapter work in an OpenAI-shaped application
Google Gemini direct	Direct provider integration	Teams whose regional and model evaluation selects Gemini	Keep a translation layer if the application contract is provider-neutral
LiteLLM	Self-hosted open-source LLM gateway	Teams that want to operate their own gateway and routing layer	You own deployment and gateway operations

This table isn't a model-quality ranking. No measured quality or latency result is supplied here, so pretending to rank those would be false precision. Run the same invoices through the candidates that meet compliance requirements, then select on validated-field accuracy and a latency percentile defined by the product team. Your mileage may vary because invoice entropy varies.

What should a Node.js SaaS send to a simple chat completions API?

The production service may be Node.js, but a standalone Python probe is useful in CI during provider evaluation and demonstrates the exact request boundary. Set INFRAI_API_KEY and choose an available INFRAI_MODEL from /v1/ai/models; don't hardcode either value. The probe first checks public discovery with an explicit method and full URL, then the OpenAI client targets the compatible base URL, sends a quality-focused instruction, bounds retries, and validates JSON locally.

import json
import os
import time
from typing import Any

import requests
from openai import OpenAI, RateLimitError

API_KEY = os.environ["INFRAI_API_KEY"]
MODEL = os.environ["INFRAI_MODEL"]

discovery = requests.get(
    url="https://api.infrai.cc/v1/discovery",
    timeout=10,
)
discovery.raise_for_status()

client = OpenAI(
    api_key=API_KEY,
    base_url="https://api.infrai.cc/v1",
    max_retries=0,
)


def extract_invoice(invoice_text: str) -> dict[str, Any]:
    for attempt in range(4):
        try:
            response = client.chat.completions.create(
                model=MODEL,
                messages=[
                    {
                        "role": "system",
                        "content": (
                            "Return JSON only with supplier_name, invoice_number, "
                            "invoice_date, currency, total, and summary. Use null "
                            "when a field is absent; never infer a missing value."
                        ),
                    },
                    {"role": "user", "content": invoice_text},
                ],
            )
            content = response.choices[0].message.content
            if not content:
                raise ValueError("The model returned no invoice content")
            result = json.loads(content)
            required = {
                "supplier_name",
                "invoice_number",
                "invoice_date",
                "currency",
                "total",
                "summary",
            }
            if set(result) != required:
                raise ValueError("Invoice output does not match the required fields")
            return result
        except RateLimitError as error:
            if attempt == 3:
                raise
            retry_after = error.response.headers.get("retry-after")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("Retry limit reached")


if __name__ == "__main__":
    sample = (
        "Supplier: Northwind Parts\n"
        "Invoice: NW-1042\n"
        "Date: 2026-07-31\n"
        "Currency: USD\n"
        "Total: 1840.00\n"
        "Items: replacement headsets for the support desk"
    )
    print(json.dumps(extract_invoice(sample), indent=2))

It is deliberately one model call. Before accepting larger inputs in the real ingestion service, use the verified token-count and cost-estimate capabilities; for many independent invoices, batch submission is simpler to operate than a loop of single requests. A batch path changes the latency promise, so it belongs to offline or deferred work rather than an agent waiting on a ticket.

No SDK wrapper can rescue a loose extraction contract. Reject extra keys, require the exact field set, and route null or contradictory totals to human review. Fast nonsense still loses.

Rejected option and its valid use case

Embeddings are the rejected option because the job is to summarize one supplied invoice and extract known fields. Adding chunk storage, retrieval, and ranking increases moving parts without serving that request. Chat completions provide the direct prompt-to-result path.

The rejection is conditional. Use embeddings later when support staff need semantic search across an invoice archive or an ask-your-docs flow. Stick with a specialist document-processing product when deterministic layout extraction, bounding boxes, or a native human-review workstation is the actual requirement; a chat summary API isn't a substitute for those capabilities. Likewise, choose a direct provider when procurement, region policy, or a provider-specific model feature outweighs gateway consistency.

Rollout record

Record the selected model ID, prompt version, schema version, token estimate, and request ID beside each result. That is enough to investigate an extraction without retaining a vague claim that "the AI did it." Keep invoice text out of general application logs, and apply the same retention policy to prompts and outputs that applies to the source document.

Re-run the representative invoice set whenever the model or prompt changes. Compare field validity first, then quality on the summary, then latency. For bulk backfills, submit batches; for an agent-facing ticket, use the single chat call and a bounded retry policy. The split is intentional.

Keep the split.

If this integration boundary fits your system, start with the Infrai documentation.

DEV Community: SullivanReed1247

Failure-First US/EU SMS Alerts: REST Templates, Suppressions, and Activity Events

Why do appointment, shipping, and account activity alerts need different lanes?

What should a simple REST API expose for US/EU templates and suppressions?

How can a provider boundary make retries and delivery state testable?

Which trade-offs matter more than a feature-count page?

How should a team roll out SMS alerts without making rollback dangerous?

Further reading

GDPR Healthtech Consent Withdrawal: FastAPI Revocation Gates at Runtime in 2026

The real bill is retained state, not the revocation request

How should consent withdrawal enforcement turn revocation into runtime access decisions?

Model grant and revoke as recoverable Python transitions

Which control plane fits the deletion workflow?

Test the denial path before shipping

References

How to Build Secure Realtime Presence Snapshots in Python: Reconnect-Safe Chat

Start with a security boundary, not a channel name

How can a customer chat use realtime presence snapshots as security controls?

What the main options get right, and where they hurt

A practical retention rule for support rooms

References

B2B SaaS Welcome Email API: DKIM, Suppression, and Polling Choices

What should a US/EU SaaS signup service own?

How do custom domain, DKIM, suppression, and event polling shape the email API choice?

Which providers fit this ownership model?

How should a safe welcome-flow rollout handle polling?

References

Further reading

Preventing Duplicate Node.js Notifications Across Bulk Email, SMS, Queues, and Pollers

How should a Node.js queue worker batch email and SMS event notifications?

Invariants and failure boundaries

Decision table

Critical path in code

Rejected option: cron as the sender of record

References

Further reading

2FA Login Fallback: SMS-to-Email OTP Without Webhooks or Provider Lock-In

What should a 2FA login fallback from SMS to email OTP own without webhooks?

Invariants and failure boundaries

Options at the provider boundary

Critical path: bounded SMS status polling

Decision and rejected option

References

Email Deliverability Provider Comparison: API Domain Verification Without SMTP Relay

The order-alert reliability contract starts before sending

Polling delivery events needs explicit backoff

How should a beginner SaaS compare an API email deliverability provider alternative to SendGrid?

How should a beginner SaaS validate provider migration and email deliverability?

References

Transactional Email Deliverability: 5 Template Preview, DKIM, Suppression Checks

The receipt cost ledger starts with one settled payment

What can template preview, domain auth, DKIM rotation, and suppression prove?

Read the contract before writing the adapter

Keep a narrow event ledger

Compare exits, not feature counts

References

SMS OTP Backend Example — 6 Cooldown and Retry Checks for Property Access

What should an SMS OTP login backend send, verify, rate limit, retry, and cooldown?

Count attempts before comparing providers

Run the two-operation harness

Retain decisions, then discard sensitive detail

Apply one acceptance decision

References

Further reading

Password Reset Email Reliability with DKIM Suppression and Bounce Recovery Explained

Reliability under bounce recovery

Implementation model for two recovery clocks

How do five password reset email API providers compare on DKIM and suppression?

Integration workflow for a pull-based email event API

Rollout of the suppression writer

References

Sources

OpenAI-Compatible Speech-to-Text Fallbacks in Node.js (EU and US, 2026)

Audio has five custody states

How should Node.js compare provider detection and speech-to-text fallback options?

A stale manifest must close the recorder

The rejected shortcut has one valid home

References

Node.js Invoice Text Summarization API: Chat Completions With Quality-Latency Controls

Invariants and failure boundaries