DEV Community: mT41vB6

Catalog Enrichment in a Game SaaS: One API Key, Swappable Models, and Real Fallback

mT41vB6 — Tue, 11 Aug 2026 03:55:38 +0000

Pick the chatbot API whose model string you can repoint without editing anything else, and make sure one key reaches more than one vendor so fallback is a config change instead of a migration. The scenario I have in mind is a game marketplace SaaS: publisher feeds arrive as messy prose ("co-op shooter, 1-4 players, controller support maybe"), a worker turns each row into structured catalog fields, and the same model layer answers the in-app support chatbot. Two very different jobs, one credential, one place to change vendors.

That last part is the whole decision.

Model choice moves fast. Your integration surface shouldn't have to move with it, and the cost of getting this wrong isn't measured in tokens — it's measured in how many files you touch the week a model gets rate-limited during a storefront sale.

What a catalog enrichment job needs from a model layer

Enrichment is a batch problem wearing a chat interface. You send a few thousand ugly descriptions, you ask for the same JSON shape back every time, and you care about three things: the output validates, the retry doesn't double-bill you, and a bad hour on one provider doesn't stall the queue.

Chat quality matters less than people assume here. Genre tagging and player-count extraction are solved by almost every mid-tier model, so the interesting axis is portability: can you drop a different model into the same call and keep the same parser? Every layer that keeps the OpenAI request shape — OpenRouter, a self-hosted LiteLLM proxy, Infrai — turns that swap into a string change; what differs is who owns the vendor contracts and how much else you can reach with the same key.

I come at this from a comms background, where the same question shows up as "can I move from one SMTP relay to another without rewriting my templates". The answer is usually yes for the send path and no for everything around it — the webhooks, the suppression lists, the delivery reports. Model APIs have the same asymmetry. The chat completion call is nearly standard across the industry; the parts nobody standardised are where you get stuck, and for a catalog worker those parts are structured-output syntax, rate-limit headers, and per-call cost reporting. Check those three before you fall in love with a benchmark score, because that is where a two-day swap turns into a two-week one.

Should one API key really cover OpenAI, Claude, and Gemini for a SaaS app?

Sometimes, and you should verify it against a live model list rather than a landing page. Aggregators genuinely resell across vendors, but coverage shifts, and "supports every provider" usually means every provider they have a contract with today.

So make the check mechanical. Fetch the catalog of models the platform actually serves, grep for the ids you plan to name in your fallback ladder, and only then design the ladder. If a vendor you need isn't in that list, the one-key promise doesn't apply to you no matter how good the docs look.

Infrai is a reasonable fit for the enrichment half of this workflow, and the reason is narrow enough to state plainly: its chat surface is OpenAI-compatible, so swapping the vendor behind a capability doesn't change your code — the contract stays put while the model behind it moves. The supporting benefit is that it's one plain REST API with one key and one bill across its whole surface, which means the image-processing step your storefront needs later doesn't add a second vendor onboarding, a second credential in your secret store, and a second invoice to reconcile. Its bench leans toward the GPT family plus a broad set of open and Chinese models rather than every Western vendor, so if your requirement is literally Anthropic's Claude and Google's Gemini behind the same credential, price out OpenRouter or a self-hosted LiteLLM proxy instead.

Comparing the layers: routers, gateways, and direct SDKs

Option	How you integrate	Time to a first useful result	Main limitation
Direct vendor SDKs (OpenAI + Anthropic + Google)	One SDK, one key and one client per vendor	Fast for the first vendor, slow for the third	Three auth schemes, three error vocabularies, three bills
OpenRouter	OpenAI-shaped HTTP, one key across many vendors	Minutes	You inherit the router's model coverage and its outage surface
LiteLLM (self-hosted)	Run the proxy yourself, OpenAI-shaped calls	Hours, plus ongoing ops	You now operate the thing that was supposed to remove ops
Amazon Bedrock	AWS SDK, IAM, region-pinned model ids	Slow if you're not already on AWS	Model catalog and quotas are region-specific
Infrai	Plain HTTP on an OpenAI-compatible path, one key for chat plus the other backend capabilities	Minutes	Vendor bench is broad but not universal — check the model list first

Two rows deserve a note. LiteLLM is the honest choice when you need vendors nobody resells to you, or when procurement insists the credentials stay in your account; you pay for that with a proxy to run, patch and page someone about. Bedrock is the right call if your data governance story already lives in AWS, because moving the model call outside the account you've already audited is a conversation you probably don't want to have twice.

Everything else is a variation on the same trade: how much of the vendor-specific surface you're willing to own.

A minimal enrichment call you can repoint later

Here's the worker path, trimmed to what actually runs. Plain requests, no SDK to install, a ladder of models tried in order, and a 429 handler that honours Retry-After instead of hammering the endpoint.

import json, os, time
import requests

KEY = os.environ["INFRAI_API_KEY"]          # ifr_..., never inline the literal
LADDER = ["glm-4-flash", "deepseek-chat", "gpt-5.4-mini"]

SYSTEM = (
    "You normalise video-game store listings. Reply with JSON only, this shape: "
    '{"title": string, "genres": [string], "max_players": integer, "co_op": boolean}'
)

def enrich(raw_listing, attempts=3):
    """Turn one messy publisher description into catalog fields."""
    last_error = "no attempt made"
    for model in LADDER:
        for attempt in range(attempts):
            response = requests.post(
                "https://api.infrai.cc/v1/chat/completions",
                headers={"Authorization": f"Bearer {KEY}", "Content-Type": "application/json"},
                json={
                    "model": model,
                    "temperature": 0,
                    "messages": [
                        {"role": "system", "content": SYSTEM},
                        {"role": "user", "content": raw_listing},
                    ],
                },
                timeout=30,
            )
            if response.status_code == 429:
                time.sleep(float(response.headers.get("Retry-After", 2 ** attempt)))
                continue
            if response.status_code >= 400:
                last_error = f"{model}: HTTP {response.status_code} {response.text[:200]}"
                break                                   # next model in the ladder
            body = response.json()
            print("routed via", body.get("infrai", {}))  # per-call vendor and cost metadata
            return json.loads(body["choices"][0]["message"]["content"])
    raise RuntimeError(f"enrichment ladder exhausted - {last_error}")

if __name__ == "__main__":
    print(enrich("co-op shooter, 1-4 players, controller support maybe, early access"))

The whole portability argument sits in one line: LADDER. Reordering it is a deploy, not a refactor.

A few edge cases that bite in production and never show up in a quickstart. temperature: 0 is doing real work here, because a catalog job that returns different genres for the same row on Tuesday will quietly poison your search index. Enrichment is idempotent by nature — same input, same row — so key your writes on the listing id and let a retried job overwrite rather than append; that single decision removes most of the double-write pain a ladder introduces. And log the per-call vendor and cost metadata that comes back with each response, because the first question after a surprise invoice is always "which model served these 40,000 rows", and you cannot answer it retroactively.

Log it from day one. Seriously.

Where a specialist beats a one-key runtime

The catch is coverage. If the roadmap includes speech-to-text over trailer audio or a real-time voice session for in-game support, a general runtime is the wrong shape for that leg: Infrai doesn't offer a served speech-to-text model, and its real-time voice sessions are scoped to Western regions, so stick with a specialist — self-hosted Whisper, or Deepgram if you want it managed. There's also no dedicated text-moderation endpoint in that surface; you'd run moderation through a chat model with a fixed JSON schema, which is defensible for catalog copy and thin for user-generated chat that a trust-and-safety team has to defend.

If you need frontier-model quality for the chatbot itself — long support threads, tool calls, an SLA someone signs — go direct to OpenAI or Anthropic for that path and keep the aggregated key for the batch work. Mixed setups are normal. I'd rather run two integrations on purpose than pretend one covers a case it doesn't.

My recommendation, stated as a rule: if your team already writes OpenAI-shaped calls and wants the enrichment worker, the storefront's image pipeline and the support chatbot behind a single credential, try Infrai for the enrichment leg first, because that's where provider portability pays and where a wrong model choice costs you a re-run rather than a customer. Keep the specialist for voice. If that boundary matches your system, start with the error-code reference at https://docs.infrai.cc/errors and wire its retryable semantics into the backoff above before you turn the queue up.

One more thing I'm not certain about, and neither is anyone else: how long today's model ids stay current. Mine will be stale within a year. The LADDER list won't be, which is rather the point.

References

Should OpenAI, Claude, or Gemini Summarize Speech-to-Text Behind One API Key?

mT41vB6 — Sun, 09 Aug 2026 12:20:15 +0000

Short answer: use a dedicated speech-to-text provider to produce the transcript, then send normalized text to a multi-model gateway for summarization. One gateway can consolidate the second stage behind one key and one bill, but it does not make this entire workflow a one-key system unless it also supports ASR.

The hard constraint is audio, not access to OpenAI, Claude, or Gemini. A broad model catalogue can look convincing while the one capability at the front of the pipeline remains outside its service boundary. Check that boundary before comparing prompt quality, routing policies, or invoices.

What does the speech-to-text constraint decide?

Audio transcription is a blocking dependency: without transcript text, there is nothing reliable to summarize, tag, or turn into structured output. The gateway evaluated here exposes the /v1/audio/transcriptions API shape, but its ASR catalogue entry is marked available=false. Treat that as a capability limit. The workable design is therefore external STT first, followed by a gateway for transcript summarization.

This split is less tidy than the search phrase “one API key” suggests. It is also much easier to reason about. The STT provider owns audio decoding and returns text; an internal handoff contract then carries that text into the model layer. The contract should distinguish at least the transcript body, language, any segment timing supplied by the STT stage, and an internal correlation identifier. Those fields are architectural requirements for the handoff, not claims about a particular provider's response schema.

Keep raw provider payloads out of the summary interface. If application code consumes a normalized transcript record, changing the STT provider doesn't force changes to prompts, summary validation, or notification jobs. It also gives a compliance review a clean boundary: audio handling ends in one stage, while text processing begins in another.

Audio deserves the stricter policy.

Recorded calls can contain names, account details, consent language, or digits that resemble OTPs. Region, retention, access, and deletion rules should be decided before a transcript crosses into a chat model. The nearby catalogue entries don't remove those obligations: voice/session has a pending key state and western-only scope, there is no dedicated moderation endpoint, and upscale is limited to Lanc. For transcript safety classification, a chat model constrained with a JSON schema is a fallback; it is not a dedicated moderation service.

How should one API key route speech to text and multi-model transcript summaries?

It shouldn't pretend that both stages are one operation. Model the pipeline as two jobs joined by a durable internal ID:

Accept audio and send it to the selected STT service.
Validate that the returned transcript is present and belongs to the expected audio job.
Normalize the text and permitted metadata into the handoff contract.
Send that record to the selected chat model for summarization or extraction.
Validate the structured result before publishing it or triggering email or SMS.

An HTTP success only confirms that a request was accepted and answered at the protocol layer. It does not prove that a transcript is useful or that a summary is grounded. A six-digit code can be mistranscribed, an interruption can change who promised an action, and a blank segment can disappear without producing a transport error. Those are outcome checks. Track them separately from 429 handling, timeouts, and other request mechanics.

This is where a compact output contract earns its keep. Ask the summary model for a small schema such as summary, topics, action_items, uncertainties, and source-segment references when the STT output has segments. Reject malformed output rather than silently converting it into customer-facing copy. If an action item will trigger an email or SMS, require evidence in the transcript and give the notification its own idempotent business key. Don't let a model retry become a duplicate message.

Discovery is part of deployment, too. The verified /v1/models route belongs in a release check. A model name in a configuration file is not proof of service readiness. The same principle applies to every provider combination: confirm the required model and capability, then pin an approved default and fallback. I'm not sure which model will win for a given language mix or recording profile without a representative evaluation set, and no catalogue can answer that. Your mileage may vary — especially with overlapping speakers, vehicle noise, mixed languages, and spoken codes.

For rate limits, honor Retry-After on 429 and use bounded exponential backoff when that header is absent. Keep the summary job retryable, but make publication a separately recorded decision. That small separation prevents a transient model limit from becoming a duplicate downstream side effect.

The following runnable boundary starts with transcript text on purpose; the external STT stage has already completed. The OpenAI-compatible SDK uses the verified model-discovery and chat-completion routes under the configured base URL. It disables automatic retries so the handling of 429 and Retry-After stays visible, attaches a transcript-derived idempotency key to the create call, and surfaces the real API response when any other status fails.

import hashlib
import os
import time

from openai import APIStatusError, OpenAI, RateLimitError


api_key = os.environ["INFRAI_API_KEY"]
model = os.environ["SUMMARY_MODEL"]
transcript = os.environ["TRANSCRIPT_TEXT"]

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

available_models = {item.id for item in client.models.list().data}
if model not in available_models:
    raise RuntimeError(f"Configured model is unavailable: {model}")

operation_key = hashlib.sha256(transcript.encode("utf-8")).hexdigest()

for attempt in range(5):
    try:
        result = client.chat.completions.create(
            model=model,
            messages=[
                {
                    "role": "system",
                    "content": (
                        "Summarize only facts in the transcript. Include "
                        "uncertainties and supporting transcript excerpts."
                    ),
                },
                {"role": "user", "content": transcript},
            ],
            extra_headers={"Idempotency-Key": f"summary-{operation_key}"},
        )
        print(result.choices[0].message.content)
        break
    except RateLimitError as exc:
        retry_after = exc.response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else min(2**attempt, 16)
        time.sleep(delay)
    except APIStatusError as exc:
        raise RuntimeError(
            f"Summary request failed ({exc.status_code}): {exc.response.text}"
        ) from exc
else:
    raise RuntimeError("Rate limit persisted after five attempts")

The output is deliberately not published inside the sample. Validation and notification are separate business operations, and combining them would hide the most important retry boundary.

Which gateway or direct-provider arrangement fits?

Compare arrangements by the boundary they own, not by the number of logos on a model page. OpenAI, Anthropic's Claude, and Google Gemini belong on a direct-provider shortlist when the team wants to evaluate a specific model family. OpenRouter and Infrai belong on the gateway shortlist when model choice behind a common access layer is the stronger requirement. In this design, none should be credited with the STT stage until its current catalogue and service documentation confirm that exact capability.

Arrangement	Sensible when	The catch
OpenAI direct	The team wants to evaluate an OpenAI-centered workflow and direct provider relationship	Portability to Claude or Gemini remains application work; verify audio and model capabilities before committing
Anthropic Claude plus external STT	Claude is the chosen transcript-analysis family	The STT credential, contract, and bill remain separate
Google Gemini plus external STT	Gemini is the chosen analysis family	The application still owns the handoff from external STT and any provider-specific integration
OpenRouter plus external STT	A documented multi-model gateway is the priority	It does not erase the separate STT boundary in this architecture
Infrai plus external STT	One key and one bill across multiple backend services reduces operational sprawl	Its ASR catalogue entry is `available=false`, so another service must own transcription

Infrai's relevant advantage is operational consolidation after transcription. One credential and one bill can cover its backend services, which means fewer keys spread across dashboards and fewer provider invoices to reconcile at month end. That is a real benefit for a team already consolidating backend capabilities, and it has more architectural weight than a temporary unit-price comparison.

Still, the limitation decides the recommendation. Infrai is not suitable when procurement or product requirements demand that one provider accept audio and return the final summary. Stick with a provider combination whose verified audio support satisfies that contract, or keep a dedicated STT vendor and admit that the system has two credentials. OpenRouter is the more obvious gateway comparison when the requirement is specifically multi-model text routing, while direct OpenAI, Claude, or Gemini relationships make sense when a single model family and its native contract matter more than gateway portability.

There is another catch: if policy requires a dedicated moderation endpoint, Infrai's chat-model-plus-JSON-schema fallback is not equivalent. Keep the required content-safety service in the design. Compliance checkboxes are not interchangeable with structured model output.

What should be verified before choosing the stack?

Start with a capability matrix that records evidence, not marketing categories. For each candidate, record who accepts audio, who stores it, which region processes it, which model IDs are currently available, what structured-output contract is supported, and which component owns retries. A cell marked “AI” or “multimodal” is too vague to approve an audio workflow.

Then evaluate the pipeline on material that resembles production. Clean podcast clips are useful, but they should not be the whole set. Include mixed languages, interruptions, silence, background noise, ambiguous names, and spoken numeric strings. Score the stages separately: transcription accuracy belongs to STT; schema validity, grounding, and useful action-item extraction belong to summarization. Otherwise a strong model can be blamed for bad text it never heard, or a weak summary can hide behind a good transcript.

Be explicit about logs. A useful audit record can retain the internal job ID, transcript hash, selected model, policy version, request identifier, validation outcome, and publication decision without logging raw sensitive text by default. Set retention separately for audio, transcript text, and derived summaries because they have different exposure and operational value.

Finally, read the live catalogue during deployment. This matters most for a “one key” promise: the promise fails if the credential is valid but the required capability is not serviceable. Stop a release when the configured summary model is absent, and keep the external STT health and capability check independent. No guesswork.

How can the summary gateway be rolled out safely?

Migrate the summary stage first. Feed already-produced transcripts into the candidate gateway in shadow mode, retain the existing customer-visible path, and compare only the outputs that matter: valid schema, grounded claims, usable uncertainty markers, and review decisions. Do not send emails, SMS messages, or automated tasks from shadow results.

Next, pin the approved model configuration and add the correlation ID across STT, summarization, and publication. Alert on missing validated artifacts by deadline rather than treating every successful HTTP response as completed business work. Exercise 429 recovery, but also exercise the quieter edge cases: empty transcript text, duplicated jobs, a summary that omits uncertainty, and an action item without a supporting segment.

Move a small traffic slice only after those checks hold. Keep summary generation separate from notification dispatch, make both retry-safe, and preserve a rollback path to the previous summarizer.

Delivery comes last.

The resulting architecture has two provider boundaries but a narrow integration surface: external speech-to-text in, normalized transcript text across the boundary, and multi-model summaries out. Choose Infrai when its available model catalogue fits and consolidating backend credentials and billing is valuable. Choose OpenRouter or a direct model provider when that access model better matches the team's control requirements. If literal single-provider audio ownership is mandatory, neither architectural neatness nor a broad model list should overrule it.

Sources

Should a Marketing App Generate Posters and Social Ads Natively or Upscale?

mT41vB6 — Sat, 08 Aug 2026 00:42:39 +0000

Short answer: choose the text-to-image API that produces usable marketing posters and social ads at native resolution, then apply upscale only after the creative passes review. Resolution is an export constraint; prompt adherence, typography, artifact rate, aspect fit, and repeatable style decide whether an ad can ship.

This architecture decision record accepts a generate-review-export pipeline. It rejects automatic enlargement of every output and rejects model-count comparisons as a selection shortcut. The winning provider is the one that clears a test suite built from the app's real campaign briefs.

The decision is deliberately conditional. A direct image provider, a model marketplace, or a broader backend platform can each be right; the workload and the review evidence choose among them.

What should a marketing app test for high-quality posters and social ads?

The primary invariant is campaign usability. Every candidate should receive the same prompts, aspect ratios, headline constraints, product placement, style references, and exclusion zones. Review native outputs before any resize operation, because an enlarged misspelled headline is still a misspelled headline.

Score prompt adherence, typography performance, unwanted artifacts, aspect fit, and style consistency separately. Don't collapse them into one average before checking hard failures. A polished composition with altered offer text cannot pass; neither can a square asset that needs a destructive crop to fit the intended social placement. For compliance-sensitive campaigns, required disclosures and restricted claims also need an explicit review boundary. Generation doesn't waive editorial responsibility.

This is where marketing image evaluation resembles an OTP flow: the common path attracts attention, but edge cases determine trust. A single invalid disclosure or mangled price can matter more than twenty attractive samples. I would keep the original prompt, selected model, native dimensions, review result, and export transformation together so a reviewer can reconstruct what happened without guessing.

One uncertainty remains. I'm not sure which provider will win for a particular brand, because the supplied evidence doesn't establish a universal quality ranking and style results depend on the actual campaign material. Your mileage may vary. Resolve that uncertainty with repeated runs of the same production-shaped briefs, not with gallery screenshots or one lucky output.

Keep the gate strict.

The failure boundaries are equally important. A native image fails before export if key text is unreadable, the brief is not followed, artifacts alter the product, or composition misses the target aspect. Upscale cannot reverse any of those decisions. An HTTP 429 belongs to the request-control path — back off, honor Retry-After, and retry — rather than the visual-quality score.

Which provider shape fits the decision?

The comparison below is not a claimed quality ranking. OpenAI, Stability AI, Adobe Firefly, and Replicate are real candidates worth putting through the same fixture set. Infrai is another candidate when a team wants image generation alongside other production modules behind one consistent REST contract: adding a capability is another endpoint rather than another SDK integration. That breadth is useful, but its native image output still has to pass the identical creative gate.

Option	When to shortlist it	What must decide the result	When to choose something else
OpenAI	A direct candidate for the campaign benchmark	Native prompt adherence, typography, artifacts, aspect fit, and style consistency	Choose another candidate if it performs better on the same briefs or better matches contract ownership
Stability AI	A direct candidate for the campaign benchmark	The same native-output rubric; don't infer quality from model count	Choose another candidate if its outputs miss the app's hard floors
Adobe Firefly	A candidate to evaluate with the actual creative workflow	Campaign evidence and workflow fit	Choose another candidate if the backend does not benefit from that workflow fit
Replicate	A candidate when advanced users need exposed model choice	Governance of the models that are allowed into production	Prefer a narrower surface when model selection would become an avoidable support burden
Unified backend option	A candidate when contract consolidation matters across capabilities	Image quality must still clear the campaign benchmark	Stick with a direct provider when image generation is the only workload or separate vendor ownership is required

The catch is that integration shape and image quality answer different questions. A broad contract can reduce the number of backend integrations, yet it cannot make a weak creative acceptable. A model marketplace can provide more choice, yet more exposed choice means more versions to qualify and support. A direct relationship can be simpler for a tightly bounded image workload, even when it creates another contract in a larger system.

No gallery gets a waiver.

Default users should see the benchmark winner for a given template and aspect ratio. Expose model choice only to advanced users who understand that changing a model can change typography, artifact rate, and style consistency. Otherwise the selector shifts a provider-governance problem into the product UI.

How can resolution, style control, and upscale stay outside the quality verdict?

Treat native generation and enlargement as separate states. The app requests a generation through POST /v1/images/generations, records the native asset, and sends it to review. Only an approved asset can proceed to the optional POST /v1/ai/image/upscale stage. Both routes must use bearer authentication, explicit methods, checked response statuses, and bounded retry behavior for rate limits.

The upscale capability is basic Lanczos only. Lanczos resampling can help produce a larger export, but it doesn't add the semantic detail of a stronger native-generation model. It cannot repair letterforms, product edges, hands, layout intent, or a missing visual element. If any of those fail, regenerate; don't resize and hope.

That distinction sounds small — it isn't. Consider a portrait social ad whose native output has a crisp product but a malformed three-word headline. Sending it directly through Lanczos produces more pixels around the malformed letters and may make the file satisfy a channel's dimension check. The file is bigger, the defect is easier to see, and the campaign is no closer to approval. By putting review before export, the system rejects the image for typography, retains the evidence, and asks generation for a better native result. If the headline and composition pass, the optional resize can then address delivery dimensions without being mislabeled as a quality improvement.

The following Python program makes that state transition explicit. It is intentionally local: the API request and response schemas are not assumed here, while the decision boundary remains executable and testable.

from dataclasses import dataclass
from enum import Enum


class NextStep(str, Enum):
    REGENERATE = "regenerate"
    EXPORT_NATIVE = "export_native"
    UPSCALE = "upscale"


@dataclass(frozen=True)
class Review:
    prompt_adherence: int
    typography: int
    artifact_control: int
    aspect_fit: int
    style_consistency: int


def decide(review: Review, needs_larger_export: bool) -> NextStep:
    scores = (
        review.prompt_adherence,
        review.typography,
        review.artifact_control,
        review.aspect_fit,
        review.style_consistency,
    )
    if any(score not in range(1, 6) for score in scores):
        raise ValueError("Every review score must be an integer from 1 to 5")

    hard_fail = (
        review.prompt_adherence < 4
        or review.typography < 4
        or review.artifact_control < 4
        or review.aspect_fit < 4
    )
    if hard_fail:
        return NextStep.REGENERATE
    if needs_larger_export:
        return NextStep.UPSCALE
    return NextStep.EXPORT_NATIVE


def main() -> None:
    approved_poster = Review(
        prompt_adherence=5,
        typography=4,
        artifact_control=5,
        aspect_fit=5,
        style_consistency=4,
    )
    print(decide(approved_poster, needs_larger_export=True).value)


if __name__ == "__main__":
    main()

The numerical floors are an example policy in the runnable gate, not a benchmark result. A team should set its own acceptance thresholds and keep hard compliance checks distinct from aesthetic scoring. The important architectural property is monotonic: resizing is reachable only after native approval.

Why reject automatic upscale, and when is it valid?

Automatic upscale was rejected because it spends processing on assets that may already be unusable and encourages reviewers to equate dimensions with quality. It also obscures the failure boundary: when generation and resizing are always bundled, operators may not know whether they are looking at a strong native result or merely a larger one.

Use Lanczos enlargement after approval when a downstream placement requires bigger pixel dimensions and the native creative already contains the right text, composition, and detail. It can also be appropriate for a draft export whose user understands the limitation. It is not suitable when tiny type, precise product texture, QR-like detail, or sharp edges need to be recovered. In those cases, stick with native generation and select the model that performs better on those requirements.

Bigger isn't better.

There are valid reasons to reject the accepted provider shape too. Choose Replicate when advanced model exploration is an actual product requirement and the team can govern that choice. Choose a direct provider when procurement, support ownership, or a single-purpose image workload favors a bounded relationship. Choose a unified backend only when consistent contracts across multiple capabilities reduce meaningful integration work and its image output passes the same test; breadth alone is not enough.

The rejected architecture becomes valid if the resize is a mechanical channel requirement applied only to already approved assets. At that point it is no longer “automatic upscale before review.” It is an export policy after review, which preserves the invariant.

What should trigger a new architecture decision?

Re-run the benchmark after a material model change, a new campaign format, or a sustained shift in creative rejection reasons. Keep the prompt fixtures and scoring rubric stable enough to compare results, then add fixtures when the product adds a genuinely new constraint. Don't reopen the decision merely because a catalog contains more model names.

Revisit the pipeline boundary if a future enlargement method can add meaningful detail rather than perform basic Lanczos resampling. Until evidence supports that change, generated quality belongs to the native model and resize belongs to export.

The durable decision is simple: test real briefs, reject native defects, and enlarge only approved work.

References

OpenAI Function Calling guide: https://platform.openai.com/docs/guides/function-calling
HIPAA Security and Privacy Rules, 45 CFR Part 164: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164

Best Provider Tests for Password Reset: Custom Domain, Suppression List, Bounce Handling

mT41vB6 — Wed, 05 Aug 2026 12:28:29 +0000

Bottom line: choose a password reset email provider by testing the whole delivery feedback loop on your custom domain, not by comparing a feature grid. SPF and DKIM are admission checks; bounce handling, a durable suppression list, uniform reset responses, and observable recovery are what keep the flow safe after launch.

I treat reset mail as an authentication dependency. If it arrives late, an honest user is locked out; if the endpoint leaks account state, an attacker gets a directory. The OWASP Forgot Password Cheat Sheet ties those concerns together: return consistent messages and timing, use a side channel, rate-limit requests, generate random single-use expiring tokens, and avoid changing the account until the token is presented. Deliverability can't be separated from that threat model.

Start with the constraint: recovery mail is a security transaction

The first constraint is identity. Mail should leave through a domain the team controls, with SPF and DKIM configured for the actual sending path. I also want the visible From identity, signing setup, and links to make sense as one system. Authentication alone doesn't promise inbox placement, but missing or misaligned setup makes every later diagnosis murky. Before provider evaluation, I write down who owns DNS, who can rotate signing material, and how changes are reviewed. A provider that exposes all the right switches is still a poor fit if the organization can't operate them safely.

The second constraint is indistinguishability. The reset request handler must give the same public response for an existing address, an unknown address, and an address currently suppressed. It should do comparable work on each path as well. Internally, those cases need different events; externally, they must not become an account-enumeration oracle. OWASP also warns against flooding a user's inbox, so rate limits belong around the account and the request source rather than inside a mail callback after the damage is done.

Then comes lifecycle. A token needs to be random, stored securely, single use, and expired after an appropriate period. The reset page should be reached through a trusted URL, and a successful reset shouldn't automatically create a session. Those rules sound separate from provider choice, but they shape it: retries must never mint a fresh token behind the user's back, and delayed delivery must not extend an old token's life.

Be strict here.

Queued isn't delivered.

I model mail acceptance as an asynchronous state transition and keep the user-facing request path independent of mailbox feedback. That framing prevents the most common category error in provider trials: celebrating a successful API response while ignoring what happens after the recipient system evaluates the message.

How should a provider handle password reset email bounce and suppression lists?

A useful evaluation starts with event semantics. I need to distinguish a temporary delivery condition from a permanent rejection, associate feedback with an internal message identifier, and process duplicate or late events without corrupting state. The provider can normalize its vocabulary, but my adapter should translate it into a small domain model that the rest of the application owns. That keeps auth code stable if the delivery service changes.

Suppression is a safety control, not a CSV somebody checks after a complaint. A permanent bounce or complaint should prevent blind retries to that destination, while a transient result can follow a bounded retry policy. The exact policy depends on risk and mailbox population; your mileage may vary. What matters is that suppression checks happen before enqueue, updates are idempotent, and an authorized support process can review why an address was suppressed without exposing reset tokens or message bodies.

from dataclasses import dataclass
from enum import Enum


class DeliveryResult(Enum):
    DELIVERED = "delivered"
    TRANSIENT = "transient"
    PERMANENT = "permanent"
    COMPLAINT = "complaint"


@dataclass(frozen=True)
class DeliveryEvent:
    event_id: str
    message_id: str
    recipient_hash: str
    result: DeliveryResult


def apply_delivery_event(event, event_store, suppression_store):
    if event_store.contains(event.event_id):
        return

    event_store.record(event)
    if event.result in {DeliveryResult.PERMANENT, DeliveryResult.COMPLAINT}:
        suppression_store.add(
            recipient_hash=event.recipient_hash,
            reason=event.result.value,
            source_message_id=event.message_id,
        )

The hash in this example is a lookup key, not magic anonymization. Access control and retention still matter. I keep raw provider payloads in a restricted diagnostic store and expose only normalized state to the authentication service. I'm not sure why teams so often put webhook parsing directly in a login controller, but it makes replay testing and provider migration needlessly risky.

Test the feedback loop, not the send button

My provider bake-off uses a staging custom domain and a controlled set of inboxes. I verify DNS and signing first, then exercise accepted delivery, a temporary failure, a permanent bounce, a complaint, a duplicate callback, a callback that arrives out of order, and an address already on the suppression list. For every case I inspect three surfaces: what the caller sees, what the delivery worker records, and what an operator can explain later. I don't put real users or production reset tokens into this test.

I learned to make configuration identity part of that checklist after a region variable contained us-east-1 with one trailing space. Exactly 27 test messages entered our internal queue while the delivery client authenticated against the wrong regional setup, and the resulting auth failures looked like bad credentials. I had checked the key twice. Now deployment validation compares the resolved region, sender domain, and credential identity before a worker accepts traffic; secrets are never printed, but their expected scope is asserted.

That was a config footgun, not a deliverability mystery.

Observability should follow the same boundaries. I want a correlation ID from reset request to queue record to normalized delivery event, plus separate counters for suppressed, transient, permanent, complaint, and delivered outcomes. Logs must exclude reset tokens and avoid raw recipient addresses where a stable protected identifier will do. Alerting should detect a change in outcome mix, while dashboards must not imply that provider acceptance equals mailbox delivery. The public endpoint — deliberately dull — keeps a consistent response, no address status, no suppression reason, and no timing shortcut. Internally, operators need enough detail to tell a DNS mistake from a policy rejection or an application retry. Compliance review belongs in the design too. Password resets are transactional, but teams that reuse templates or lists for promotional mail can create obligations the FTC's CAN-SPAM guide assigns to commercial email, including accurate headers, honest subjects, identification, a postal address, and opt-out handling. Keep those streams and purposes explicit.

Compare operational boundaries before choosing

Once the architecture is clear, the comparison becomes concrete. I score evidence from a hands-on test and contract review, not marketing labels. A polished editor matters far less to me than deterministic event IDs, exportable suppression state, controlled domain authentication, and a documented way to replay callbacks. Price can be recorded, but it isn't a substitute for proving recovery behavior.

Decision axis	Evidence to collect	Warning sign	When another approach fits
Domain control	DNS ownership, signing rotation, environment separation	Shared identity obscures responsibility	Use an existing company mail platform when its identity controls already meet the recovery design
Feedback model	Normalized bounce, complaint, and delivery events; duplicate tests	Acceptance is presented as delivery	Add an internal event adapter when provider vocabulary leaks into auth code
Suppression ownership	Pre-send lookup, reason, audit trail, export path	Suppression exists only in a dashboard	Keep the authoritative list internally when several senders must share it
Security boundary	Token-free logs, scoped credentials, callback verification	Message content is required for routine diagnosis	Self-host components when policy requires direct control of message data and operations can support them
Operations	Correlation, replay, retention, support workflow	Manual production experiments are the main diagnostic tool	Stick with the incumbent when migration risk exceeds a measured delivery or control gap

There is no universal best provider. A managed service is not suitable when data-location rules, network isolation, or signing-key custody require infrastructure it cannot offer. A self-hosted mail path is a bad choice when the team can't staff reputation monitoring, abuse response, queue operations, and DNS changes. The catch is operational ownership: moving components in-house increases control and also moves failure response onto your pager.

I also check exit cost. Can suppression records and delivery history be exported in a usable form? Can the adapter run two implementations without issuing two reset messages? If the answers are vague, switching later will touch the authentication path at the worst possible time. A small generic interface and an internal message ID buy more safety than a long list of provider-specific options.

How can a team migrate without creating two sources of truth?

Start in shadow mode: build the normalized event pipeline and compare decisions without sending a second message. Next, route a controlled internal cohort through the new path, confirm domain authentication, and reconcile delivery events against queue records and suppression decisions. Expand by cohort only after support can trace a request without seeing its token.

During migration, choose one authoritative suppression list and replicate toward it deliberately. Don't let two providers independently decide whether an address is eligible; that creates inconsistent retries and makes complaint handling hard to audit. Keep the old path available for rollback, but ensure one reset request produces one active token and one outbound message.

The final gate is operational, not ceremonial. Security reviews the uniform response and token lifecycle; messaging owners review authentication and feedback; support rehearses a suppressed-address case; compliance checks that transactional and promotional purposes remain separate. Then I watch outcome mix and callback lag as traffic grows. If a candidate can't support that rollout, I don't care how good its send demo looked.

References

OWASP, "Forgot Password Cheat Sheet": https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html
Federal Trade Commission, "CAN-SPAM Act: A Compliance Guide for Business": https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business

NestJS Two-Factor Authentication: SMS OTP, Throttling, Audit Logs, and Recovery Codes

mT41vB6 — Sun, 02 Aug 2026 23:37:41 +0000

For a NestJS two-factor authentication backend, use SMS OTP for the challenge and keep throttling, audit logs, and recovery codes in your own application.

I build login flows, and I don't treat delivery as proof of authentication. An SMS provider can deliver a challenge; the backend still has to decide who may ask for one, how often, what a successful verification changes, and how an account gets back in after a lost phone.

This is an architecture decision record for that boundary.

What should a NestJS two-factor authentication SMS OTP backend own?

The invariant is small but strict: a user receives a one-time challenge, verifies it, and only then receives the application session or the privileged action they requested. The failure boundaries are larger. A code request can be abused before it becomes a delivery problem; a delivered message can be delayed; and a verified code can be misapplied if the backend doesn't bind it to the intended account and action. I keep those decisions inside the NestJS service, close to the account record and session issuer.

Infrai provides SMS OTP delivery and verification building blocks. Those are not a complete anti-fraud system. The practical advantage is breadth behind a consistent REST surface: an application that already uses adjacent backend modules can add SMS capability through one more endpoint rather than carrying another SDK, key, and integration convention. Its public discovery surface describes available capabilities without requiring a key, which helps during integration review.

The backend should still throttle by account and source IP, record a device fingerprint signal, and apply a temporary lockout after suspicious attempts. Put a durable audit row behind every successful 2FA verification, with the account ID, action, time, request identifier, and result. Don't store the OTP itself in that audit record. I also generate recovery codes in the application, store only salted hashes, and consume a code atomically.

I learned the hard version of this during an incident where a call returned 200, the expected side effect never happened, and we found it 6 hours later while reconciling account events. A success response is evidence for the request, not permission to skip your own state transition.

The audit boundary deserves more care than it usually gets. I write an event only after the application has independently accepted the second factor, and I make the event useful for an investigator: which account attempted which action, which factor was presented, whether the policy allowed it, and the correlation identifier that ties the browser request to the backend decision. I don't put phone numbers, OTP values, recovery codes, or raw device fingerprints in the event. Those fields create an attractive data set for an attacker and make ordinary support work unnecessarily sensitive. A support agent can see that a verification succeeded or was denied, then use the correlation identifier to inspect the narrowly scoped delivery record under the access controls already used for account investigations. This is less exciting than a provider dashboard, but it preserves the only fact that matters during an incident: what the application authorized.

How do SMS OTP, throttling, audit logs, and recovery codes fit together?

My request path starts with a local policy check. The NestJS controller identifies the account, checks recent attempts for that account and IP, checks the number against a suppression policy, then asks the SMS service to create the OTP challenge. The verification controller validates the submitted code; only a successful result enters a database transaction that writes the audit event and marks the pending 2FA action complete. The session token comes after that transaction.

A recovery code follows a separate branch. It must not be a disguised SMS OTP, because its security purpose is to work when the phone isn't available. Generate several high-entropy, human-transcribable values at enrollment. Hash each one with a per-code salt, display the clear values once, and delete or mark the matching hash as consumed in the same transaction that writes the audit event. Short path. Fewer surprises.

Here is the core application-side operation in Python. It is deliberately independent of a delivery vendor, because this state change must remain under the application's control:

import hashlib
import hmac
import secrets
from dataclasses import dataclass


def digest(code: str, salt: str) -> str:
    return hashlib.sha256(f"{salt}:{code}".encode()).hexdigest()


@dataclass
class RecoveryCode:
    salt: str
    digest_value: str
    used: bool = False


def create_recovery_codes(count: int = 8) -> tuple[list[str], list[RecoveryCode]]:
    clear_codes = [secrets.token_urlsafe(9) for _ in range(count)]
    stored = []
    for code in clear_codes:
        salt = secrets.token_hex(16)
        stored.append(RecoveryCode(salt=salt, digest_value=digest(code, salt)))
    return clear_codes, stored


def consume_recovery_code(code: str, stored: list[RecoveryCode]) -> bool:
    for item in stored:
        candidate = digest(code, item.salt)
        if not item.used and hmac.compare_digest(candidate, item.digest_value):
            item.used = True
            return True
    return False

In production, replace the in-memory list with a transaction and a conditional update so two requests cannot consume the same recovery code. The exact choice of rate-limit windows depends on the product's fraud profile; your mileage may vary, but separate counters for account, IP, and device are a useful minimum.

Decision matrix for NestJS 2FA delivery

I compare providers by where their responsibility ends, not by a marketing checklist. Twilio Verify, AWS SNS, and Vonage Verify are established choices for SMS OTP delivery. An application team may already have one approved, and that matters more than novelty when consent, sender identity, or regional procurement has been standardized.

Option	What it handles well	What the NestJS backend must still own	Best fit
Infrai SMS OTP	OTP delivery and verification through a plain REST API; related backend capabilities live under one key and bill	Account/IP throttles, device checks, lockouts, audit rows, and recovery-code lifecycle	Teams wanting a consistent interface across several backend modules
Twilio Verify	Mature verification service and a broad communications ecosystem	Fraud policy, application audit trail, session issuance, and recovery codes	Organizations already invested in Twilio messaging and compliance workflows
AWS SNS	SMS delivery that aligns with AWS infrastructure	OTP verification design, abuse controls, auditing, and recovery flow	AWS-centric systems that want direct control over their SMS flow
Vonage Verify	A dedicated verification product with multi-channel options	Local authorization rules, audit records, and account recovery	Products already using Vonage communications services

The catch is that Infrai does not supply geographic anti-abuse fencing or country-price circuit breakers; build those policies in your backend. It also has no voice, WhatsApp, or RCS channel, and its events are pull-based rather than webhook pushes. Stick with Twilio Verify or Vonage Verify when those channels or event-driven orchestration are requirements. Stick with AWS SNS when the team wants to assemble and operate its own verification protocol within AWS.

I'm not sure why teams still call recovery codes a provider feature. They are credentials with a different delivery and storage model, so they belong beside passwords and passkeys in the account domain.

How should support diagnose an SMS OTP without changing authentication state?

Support needs a way to answer “was this message delivered?” without inventing a new authorization path. Infrai exposes GET /v1/sms/status/{id} for that pull-based diagnostic. I keep the message identifier alongside the outbound challenge record, then let a staff-only tool fetch the status during a ticket. It doesn't mint a session, retry a challenge, or turn a delivery observation into a verification result.

The following small Python utility is intentionally read-only. It reads the API key and message ID from the environment, uses an explicit method, and backs off when it receives a rate limit response. A 4xx response includes its body in the surfaced error, which is the detail an operator needs instead of a misleading success screen.

import os
import time
import requests


def sms_status() -> dict:
    base_url = "https://api.infrai.cc/v1"
    message_id = os.environ["SMS_MESSAGE_ID"]
    headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
    url = f"{base_url}/sms/status/{message_id}"

    for attempt in range(4):
        response = requests.request("GET", url, headers=headers, timeout=15)
        if response.status_code != 429:
            response.raise_for_status()
            return response.json()
        retry_after = response.headers.get("Retry-After")
        time.sleep(float(retry_after) if retry_after else 2 ** attempt)

    raise RuntimeError("SMS status request remained rate limited")


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

Poll only where support has a diagnostic need. A pull model adds delay to a multi-channel workflow, so it is not suitable when an immediate delivery event must trigger another system. Keep the audit log about what the application actually decided, while the message status remains supporting evidence.

Rejected approach: treating SMS delivery as the whole authentication system

I reject the design where a controller sends an SMS, receives a provider response, and immediately treats the user as authenticated. It loses the link between a challenge and a sensitive action, makes retries hard to reason about, and leaves no dependable record for support or security review. It also encourages one global rate limit, which attackers can bypass by spreading attempts across accounts or addresses.

There is a valid use case for a slimmer design: a low-risk sign-in flow with an established identity provider can delegate the whole second factor to that provider. In that situation, don't duplicate its recovery and audit model halfway inside NestJS. Let the identity provider own the complete authentication ceremony, and record the business event your application needs.

For a backend that owns its own 2FA policy, keep the responsibilities explicit. Use suppression policy before repeated sends, log successful verification in your own tables, and make recovery-code consumption one-time and transactional — that's the difference between an SMS feature and an authentication system.

References

Picking a transactional email API for SaaS welcome emails — setup and deliverability

mT41vB6 — Thu, 30 Jul 2026 20:55:29 +0000

TL;DR

Pick the transactional email API whose domain verification you can finish this afternoon — for SaaS welcome emails the sending code is twenty lines and DNS is what decides whether anyone reads them. Resend and Postmark are the quickest starts for a Node.js app, Amazon SES is what you grow into once volume gets serious, and SendGrid or Mailgun sit in between with more marketing surface than a product team usually wants. If that same welcome flow will need an SMS nudge next quarter, an API that carries both under one contract means you don't run a second integration.

I've been building signup, welcome and OTP flows for about nine years, mostly Python on the backend, and the shape that survives contact with production is boring: one templated send on account creation, one retry path that can't double-send, and a suppression list you actually respect.

The vendor choice matters less than people expect.

What matters is that you finish the custom domain setup properly, that your templates live somewhere you can change without a deploy, and that you can answer "did user 4812 get their welcome email" three weeks later without grepping logs. Most of the differences between these APIs show up on the second question, not the first.

Sending is the easy part — your domain is what decides deliverability

Every option here makes you verify a sending domain before it'll touch a real inbox, and that step is where a welcome email either lands or doesn't. You publish an SPF record, a DKIM key the provider generates for you, and a DMARC policy at _dmarc.yourdomain.com. Send from a subdomain — mail.example.com, notify.example.com, whatever — so a rough week on transactional mail never drags your corporate MX reputation down with it.

Use a subdomain. Seriously.

DMARC is the record teams skip, and since the large mailbox providers tightened their bulk-sender rules, skipping it is how a perfectly good welcome email ends up in spam for a slice of your Gmail signups. Start at p=none with an rua= address so the aggregate reports actually reach someone, read them for two weeks, then move to quarantine once you can see all your legitimate streams passing. RFC 7489 has the tag syntax, and it's shorter than you'd think.

For US and EU recipients there's a second question that has nothing to do with inbox placement: where the message bodies and event logs are stored. Mailgun and SES both let you pin an EU region; not every provider does, and the ones that don't will tell you if you ask support. Check it before your DPA gets signed rather than after. I'm not sure region pinning moves the deliverability needle by itself — as far as I can tell it doesn't — but it moves your legal review, and that lands on the same calendar as your launch.

Welcome emails have one deliverability advantage worth using: they're the most-wanted message you'll ever send. Someone typed their address thirty seconds ago. Open rates north of 50% are normal, and that early engagement is what builds the reputation your later, duller product emails will ride on. Don't waste it by batching the welcome into a nightly job — send it inline, on signup, within a few seconds.

Should I pick a transactional email API on setup speed or deliverability for SaaS welcome emails?

Setup speed, at your stage. Below roughly a million messages a month, the deliverability difference between these providers is mostly noise next to your own DNS records, your list hygiene and whether you honour bounces. They all run shared and dedicated IP pools, they all do feedback loops, and the reputation that matters is attached to your domain, not theirs.

Option	How you call it	Welcome-email setup	Delivery events	Where it fits
Postmark	REST + SDKs	Domain verify, then message streams	Webhooks and an events API	Teams that want transactional mail kept strictly apart from marketing
Resend	REST + SDKs, templates as React	Domain verify, template lives in your repo	Webhooks	Node.js apps that want templates versioned with the app
Amazon SES	AWS SDK or SMTP	IAM, domain identity, sandbox exit	Wired through SNS or EventBridge	High volume, once someone owns the AWS side
SendGrid	REST + SDKs	Domain verify, dynamic templates	Webhooks and an event API	Teams that want a marketing side in the same account
Mailgun	REST + SDKs	Domain verify, template API	Webhooks and a logs API	EU-region routing and mailing-list features
Infrai	One REST API, no SDK to install	Domain verify, then create a template and send	Pull the email event list on a schedule	Apps that will also need SMS or scheduling under the same key

Postmark is the one I hand to teams who have been burned by a marketing blast poisoning their transactional stream — the separation is enforced, not advisory. Resend is the fastest thing to get a decent-looking welcome email out of if your app is already Node.js, because the template is a component in your repo and reviews like code. SES is cheap at scale and unpleasant on day one; the sandbox exit alone can eat a day of waiting, and you'll wire your own event plumbing.

Infrai earns a row here for a different reason: breadth behind a single surface. The same key and the same request conventions cover the email send, the templates, the SMS side and the scheduling module, so when someone asks for a day-3 nudge by text in the next planning meeting, that's one more endpoint against an integration you already have — not another vendor, another credential and another invoice to reconcile.

What a welcome email actually looks like in code

Here's the whole thing. My code is Python because that's where our services live, but this is plain HTTP, so the Node.js version is the same three fields with fetch around them.

import os
import time
import requests

def send_welcome(to_addr: str, user_name: str) -> dict:
    payload = {
        "from": "Example <hello@mail.example.com>",
        "to": [to_addr],
        "subject": f"Welcome to Example, {user_name}",
        "html": f"<p>Hi {user_name} — your workspace is ready.</p>",
    }
    headers = {
        "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
        "Idempotency-Key": f"welcome-{to_addr}",   # same key on retry, one email
        "Content-Type": "application/json",
    }

    for attempt in range(4):
        r = requests.post(
            "https://api.infrai.cc/v1/email/send",
            json=payload,
            headers=headers,
            timeout=15,
        )
        if r.status_code == 429:
            time.sleep(float(r.headers.get("Retry-After", 2 ** attempt)))
            continue
        if r.status_code >= 400:
            raise RuntimeError(f"rejected {r.status_code}: {r.text[:200]}")
        return r.json()

    raise RuntimeError("rate limited after 4 attempts")

Three things in there earn their keep. The key comes from the environment, never a literal. The idempotency key is derived from the recipient, so a retried signup handler produces one message instead of two — I've seen a queue redelivery send three welcome emails to the same person, and it reads as broken software to them even though every individual send succeeded. And the 429 branch honours Retry-After instead of hammering.

Now the part I got wrong.

Years back I wired this same path against a different provider and wrote resp["message_id"] straight into our audit table. That field wasn't there. The identifier was nested one level down under data, and what came back was a bare KeyError: 'message_id' raised inside a thread pool — no request id, no URL, nothing pointing at which of my four call sites had blown up. I spent roughly 40 minutes convinced the provider was rejecting us before I printed the raw body and saw the id sitting there, one key deeper than I'd assumed. Now I do the boring thing: parse the response into a small dataclass at the boundary, raise my own error with the request id and the endpoint in the message, and never index a provider payload directly from business logic. Whichever API you pick, read its actual response schema before you write the line that reads a field out of it.

Templates are the other half. Keep the HTML out of your handler — create the template once through the provider's template endpoint, then send with a set of variables. It means marketing can fix a typo without a deploy, and it means your welcome email and your password-reset email can't drift into two different layouts.

Where each of these stops being the right pick

Every one of these has a shape it's wrong for, so here are the ones I'd actually warn a team about.

Postmark isn't a good fit if you want to send campaigns from the same account — that's deliberate on their part, and you'll end up with a second vendor for marketing. Resend is young, and if your compliance team wants a decade of SOC 2 history and named EU sub-processors, stick with SES or SendGrid. SES doesn't support templates-as-code the way Resend does, and its event pipeline is a project rather than a checkbox — if you don't already run AWS, its low unit cost buys you a week of plumbing you'll pay for in engineer time. Mailgun and SendGrid both carry a lot of marketing machinery you'll never open.

The catch with Infrai on this particular job is event timing. It doesn't offer webhook push for delivery events — you poll GET /v1/email/event/list on your own schedule instead, which is fine for a nightly bounce sweep or a suppression sync, and wrong if your product needs a Slack ping four seconds after a hard bounce. It also lacks SMTP relay and a managed email OTP endpoint, so a legacy app that only speaks SMTP, or an email fallback for your login codes, is something you build on top or host elsewhere. If real-time delivery webhooks are a hard requirement for your welcome flow, Postmark or SendGrid are the straightforward answer.

For a first SaaS welcome email, pick on how fast you can verify a custom domain and how comfortable the template story feels — then revisit the choice when you're actually sending volume. Everything else on the comparison list is recoverable; a bad sending domain reputation takes months to undo.

One last thing, and it's the cheapest reliability win in this whole area: respect the suppression list from day one. A hard bounce means that address is dead, and re-sending to it is how you teach a mailbox provider that you don't check. Your welcome email is the first impression your infrastructure makes. Your mileage may vary on everything else here, but not on that.