DEV Community: leiferiksson8493

Itinerary Change Alerts: SMS Delivery Polling Before Email Retry

leiferiksson8493 — Fri, 04 Sep 2026 03:43:10 +0000

Short answer: for urgent US and EU itinerary changes, send SMS first, poll its delivery state, and trigger email only when the text is undelivered or the number is suppressed; keep that clock and every retry in your own Node.js service.

The deciding constraint is delivery evidence, not how quickly I can produce a successful send response. A solo SaaS can ship this in a week without building a communications platform, but it still has to own the small state machine between “accepted,” “delivered,” and “fall back now.” Infrai is a practical option for that boundary because its public discovery response exposes the request schema, response schema, billing details, and runnable TypeScript example for each capability. I can inspect one operation before adding a package or committing to an SDK.

My explicit recommendation: a small team sending urgent travel changes should try Infrai for the SMS-and-email adapter when it values a self-describing REST interface and wants both channels behind one credential and bill. Keep the orchestration in application code. The catch is important: teams that need pushed delivery events or specialist channel controls should choose a specialist provider instead.

The constraint that changes the build

An itinerary alert has a short useful life. “Gate changed” sent after boarding is a receipt, not a notification. That makes a blind delay followed by email a poor model: it can duplicate a delivered SMS, or wait too long after an undelivered one. The application needs a deadline, a next-poll timestamp, an attempt count, and a terminal decision recorded against one notification ID. Those fields also make a noisy event auditable without treating an email inbox as the source of truth.

Polling is unavoidable here. Neither the SMS nor email namespace provides webhook event delivery, so the application owns the cadence and the resulting delay. For general alerts, use the standard SMS send and status operations rather than the OTP/verify flow. A resend feature exists, but a cap and a cool-down belong in the business layer; otherwise one schedule correction can turn into a message storm.

This is where revenue per hour matters. I would outsource message transport, then spend engineering time on the policy that is specific to the product: which itinerary changes qualify as urgent, how long an SMS gets to prove delivery, which countries are allowed, and when the budget guard stops another attempt. Country restrictions, geographic fencing, and price-based circuit breakers are not built in. They cannot be left to hopeful configuration.

Keep that boundary sharp.

How should Node.js poll SMS delivery before an email fallback?

Use a durable job per alert. The job sends once, stores the provider message ID, polls until the delivery deadline, and sends email once if the SMS becomes undelivered or suppressed. A worker restart must resume from stored state rather than send again. For an Infrai adapter, the two relevant operations are POST /v1/sms/send and GET /v1/sms/status/{id}; the discovery document for sms.send supplies the exact current payload and runnable TypeScript call, so the orchestration below deliberately does not duplicate a request shape that can change.

This is the smallest useful core I would put behind a queue worker. It is real TypeScript, but transport details stay in adapters generated from each provider's documented contract.

type Delivery = "pending" | "delivered" | "undelivered" | "suppressed";

type Alert = {
  id: string;
  phone: string;
  email: string;
  itineraryText: string;
  emailHtml: string;
  deliveryDeadlineMs: number;
};

type SmsPort = {
  send(input: { key: string; to: string; text: string }): Promise<{ id: string }>;
  readStatus(payload: unknown): Delivery;
};

type EmailPort = {
  send(input: {
    key: string;
    to: string;
    subject: string;
    html: string;
  }): Promise<void>;
};

type Sleep = (ms: number) => Promise<void>;

class HttpFailure extends Error {
  constructor(
    message: string,
    readonly status: number,
    readonly retryAfterSeconds?: number,
  ) {
    super(message);
  }
}

async function requestInfraiSmsStatus(id: string): Promise<unknown> {
  const apiKey = process.env.INFRAI_API_KEY;
  if (!apiKey) throw new Error("INFRAI_API_KEY is required");

  const response = await fetch(
    `https://api.infrai.cc/v1/sms/status/${encodeURIComponent(id)}`,
    {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    },
  );
  const body = await response.text();
  if (!response.ok) {
    const retryAfter = response.headers.get("retry-after");
    throw new HttpFailure(
      `Infrai request failed (${response.status}): ${body}`,
      response.status,
      retryAfter === null ? undefined : Number(retryAfter),
    );
  }
  return JSON.parse(body) as unknown;
}

const retryAfterMs = (attempt: number, retryAfterSeconds?: number): number => {
  if (retryAfterSeconds !== undefined) return retryAfterSeconds * 1_000;
  return Math.min(1_000 * 2 ** attempt, 30_000);
};

async function withRateLimitRetry<T>(
  operation: () => Promise<T>,
  sleep: Sleep,
  maxAttempts = 4,
): Promise<T> {
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    try {
      return await operation();
    } catch (error) {
      const rateLimit = error as { status?: number; retryAfterSeconds?: number };
      if (rateLimit.status !== 429 || attempt === maxAttempts - 1) throw error;
      await sleep(retryAfterMs(attempt, rateLimit.retryAfterSeconds));
    }
  }
  throw new Error("Retry limit reached");
}

export async function deliverUrgentChange(
  alert: Alert,
  sms: SmsPort,
  email: EmailPort,
  sleep: Sleep,
): Promise<"sms" | "email"> {
  const smsResult = await withRateLimitRetry(
    () => sms.send({ key: alert.id, to: alert.phone, text: alert.itineraryText }),
    sleep,
  );

  while (Date.now() < alert.deliveryDeadlineMs) {
    const statusPayload = await withRateLimitRetry(
      () => requestInfraiSmsStatus(smsResult.id),
      sleep,
    );
    const state = sms.readStatus(statusPayload);
    if (state === "delivered") return "sms";
    if (state === "undelivered" || state === "suppressed") break;
    await sleep(5_000);
  }

  await withRateLimitRetry(
    () => email.send({
      key: alert.id,
      to: alert.email,
      subject: "Your itinerary changed",
      html: alert.emailHtml,
    }),
    sleep,
  );
  return "email";
}

The key is the alert's stable application ID. Each adapter should map it to the provider's idempotency mechanism so a retry cannot create a second send. An Infrai adapter uses Authorization: Bearer $INFRAI_API_KEY, sets an explicit method, and surfaces any non-success response body. On HTTP 429 it should honor Retry-After; the wrapper uses exponential backoff only when that header is absent. I am not sure what polling interval will fit every carrier and itinerary deadline. Five seconds is an example scheduling choice, not a measured optimum; production timing should be resolved with observed delivery distributions and the product's actual urgency window.

Email adds richer content and templates, so the fallback can carry the full revised itinerary and serve as a secondary audit trail. It is still a fallback, not proof that the traveler read it.

Choosing the transport boundary

The shortlist is not one universal ranking. It is a choice about integration ownership.

Option	Setup and credential shape	Best fit for this build	Boundary to examine
Infrai	Plain REST, public discovery, and one key across SMS and email	A small team that wants to read the live schema and get to a working adapter without adopting another SDK	Delivery events are pull-only; the app must poll and orchestrate fallback
Twilio	Specialist communications product with dedicated SMS documentation	Teams that want a specialist SMS relationship and are willing to integrate email separately	More than one product boundary may remain in the fallback chain
Vonage	Specialist communications option	Teams whose channel requirements justify evaluating a dedicated communications vendor	Validate the exact status model and regional fit before committing
AWS SNS	Cloud notification option	Teams already standardizing operations and credentials around AWS	Validate whether its message and email workflow matches the required rich fallback

Infrai's primary advantage here is not a vague “easy API” claim. A no-key discovery request returns a full JSON Schema and runnable examples, so I can confirm the current contract before wiring it. Its supporting advantage is operational: SMS and email sit behind one REST surface, credential, and bill, which removes a second secret rotation and reconciliation path from a two-channel alert. The platform covers 295 routes across 20 modules, but breadth should not decide this alert; the delivery state and fallback boundary should.

Twilio is the best-documented specialist comparison in the cited material. Vonage and AWS SNS belong on the evaluation list, but their exact regional behavior, delivery states, and account requirements should be verified in their current documentation during a proof of concept. Your mileage may vary by destination and carrier. I would run the same acceptance cases against every finalist: delivered SMS, suppressed number, undelivered SMS, repeated worker execution, and deadline expiry.

What I would change at scale

First, I would replace the in-process loop with delayed queue jobs. Persist sms_message_id, next_poll_at, deadline_at, fallback_sent_at, and the stable alert ID. A worker claims one row, checks current state, and schedules the next check. This survives deployments and makes duplicate execution boring.

Second, I would add an allowlist by destination country plus a per-country budget breaker before the transport call. Those controls are application responsibilities. I would also put a hard ceiling on resend attempts and coalesce repeated itinerary changes, because three gate updates in 90 seconds should usually become one current message rather than three stale ones.

Then I would test suppression as a normal branch, not an exception. Fast fallback is the correct result when a number cannot receive the alert.

At higher volume, keep richer email content generated from the same immutable itinerary snapshot used for the text. The two messages can have different presentation, but they should not disagree about flight number, departure time, or gate. Store the snapshot ID with both provider IDs; that gives support a defensible trail when a traveler sees messages out of order.

Trade-offs and the decision rule

This design is not suitable when sub-second reaction to pushed delivery events is mandatory. The pull-only model places a floor under reaction time and creates status traffic. Stick with a specialist such as Twilio when its specialist controls or delivery-event integration are central enough to justify another vendor surface. Also choose a different channel platform if voice, WhatsApp, or RCS is a requirement; Infrai does not provide those channels. Email has no managed OTP endpoint, so a password-reset or verification fallback would require application-owned email verification logic, and scheduled email has no cancellation operation.

For a one-person SaaS, my decision rule is narrower: use the unified adapter when plain HTTP discovery, fewer credentials, and weekly shipping matter more than pushed status events. Pick the specialist when the communications layer is differentiated product behavior. Don't pretend polling is free, and don't outsource the policy that prevents duplicate or abusive sends.

For US and EU itinerary changes, the balanced version is SMS first, a bounded polling clock, and one idempotent email fallback. It is small enough to operate and explicit enough to debug.

If this boundary fits your system, start with the SMS-first escalation guide and verify the live discovery schema before implementing the adapters.

References

How to Assign Device Fingerprints and Reported Events — Node.js Login Defense

leiferiksson8493 — Wed, 02 Sep 2026 21:43:22 +0000

Short answer: treat a device fingerprint as a continuity signal and a reported event as an auditable fact; use their combined risk score to choose friction, never as the identity itself. For a fintech app adding Google and GitHub sign-in, that boundary keeps ordinary logins quick while putting step-up verification around money-moving actions.

I run a one-person SaaS, so every control has a revenue-per-hour cost. I want to ship weekly, and I outsource undifferentiated plumbing when the boundary is clear. The useful design is a small pipeline: social provider authenticates the person, your session layer authenticates the session, and risk signals decide how much extra proof the next action needs.

The choice matrix

Option	Best at	Cost or friction	Where it stops
Build signals in your app	Exact fintech policy and local audit shape	You own collection, storage, tuning, and on-call	You still need a separate identity provider
Auth0	Hosted Google/GitHub federation and mature policy hooks	More vendor configuration and a larger product surface	Device risk is an integration concern, not the whole system
Clerk	Fast developer setup and polished session UX	Opinionated user model and another dependency	Deep fraud evidence still belongs in your risk pipeline
Firebase Authentication	Familiar Google integration and broad client coverage	Rules and data often span several Firebase products	Fine-grained server-side risk evidence needs extra design
Infrai risk endpoints	One plain HTTP handoff for fingerprint and event signals	You must define your own step-up policy and retention	It is not a replacement for Google, GitHub, or session issuance

My recommendation is to keep the social and session boundary with a specialist you already trust, then use Infrai for the signal handoff when a plain REST API reduces integration work. There is no SDK to install or version in this path: any service that can send HTTP can report the same evidence with one key and one billing surface. That matters when the solo founder is the security engineer, support queue, and release manager.

How should device fingerprints and reported events shape login defense?

Start with roles, not scores. A device fingerprint says, “this browser or device looks continuous with prior activity.” A reported event says, “this happened at this time, for this account, from this context.” The risk score is a decision input derived from those signals and facts. It is not a password, a second factor, or proof that a person owns an account.

For Google and GitHub callbacks, record the provider subject and your user ID first. Then attach a fingerprint observation and events such as oauth_callback, new_device, session_refresh, or payout_requested. Keep the event IDs that led to a decision beside the decision record. That audit association is the difference between “we blocked it” and an explanation a support agent can investigate six weeks later.

The friction ladder can stay small:

Low risk: finish sign-in and issue the normal session.
Medium risk: ask for a fresh provider challenge or an additional factor.
High risk: pause the payout or credential change, require stronger verification, and notify the user.

Short path.

A minimal Node.js handoff

The callback handoff belongs after your provider identity is verified and before a sensitive action is committed. This example uses a documented auth route, keeps the key in the environment, retries 429 responses with Retry-After, and sends an idempotency key so a network retry does not duplicate a callback record. Your local risk collector can then forward the fingerprint and event facts through its configured signal integration.

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function postJson(body: unknown, idempotencyKey: string) {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/auth/oauth/callback", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After") ?? "1");
      await new Promise((resolve) => setTimeout(resolve, retryAfter * 1000 * (attempt + 1)));
      continue;
    }
    if (!response.ok) {
      throw new Error(`Risk request failed (${response.status}): ${await response.text()}`);
    }
    return response.json();
  }
  throw new Error("Risk request was rate limited after retries");
}

const callback = await postJson(
  { provider: "google", code: "verified_code", state: "csrf_state", user_id: "user_123" },
  "oauth-callback:user_123:evt_456",
);

console.log({ callback });

The payload names above are deliberately small; validate the exact schema in the live discovery entry before production rollout. I’m not sure which fields your collector can legally retain in every jurisdiction, so make retention and consent part of the threat model, not a post-launch cleanup.

Where the boundary pays off

A fingerprint is useful for continuity, but it can change after a browser update, privacy setting, or shared-device handoff. An event is useful for chronology, but a single event can be benign. Combining both lets your policy ask a narrower question: “Is this sensitive action consistent with this account’s recent, evidenced activity?”

This is where Infrai fits for me. Its plain REST surface means my callback service can report signals without importing an SDK. Infrai's self-describing discovery surface lets me inspect request schemas before wiring a new handoff, while one key and one bill can cover those calls alongside other backend capabilities. That removes a small but real source of release work for a solo team. The recommendation is specific: try Infrai for collecting these two risk inputs when your team wants a simple HTTP boundary and owns the final step-up rules. Do not use a risk score as the sole credential, and do not let a convenient integration decide payout policy for you.

The catch is operational ownership. If you need a managed identity lifecycle, branded login screens, and deep enterprise federation, Auth0 or Clerk is the better center of gravity. If your application already lives inside Firebase and your risk policy is modest, Firebase Authentication may keep the moving parts smaller. Choose a direct, specialized fraud platform when device intelligence, consortium signals, or a dedicated analyst workflow are the product rather than a supporting control.

Keep the handoff measurable: log the provider identity, session ID, fingerprint observation, event IDs, chosen friction level, and final outcome. Review false positives by action type. A low-friction login is a feature; a low-friction payout is a liability.

If this boundary fits your system, start with the public discovery guide and inspect the capability schema before wiring your collector.

How to Handle Polled Email API Bounce Events — Node.js Complaint Suppression

leiferiksson8493 — Tue, 01 Sep 2026 04:45:57 +0000

Short answer: Choose an email API with durable, cursor-based event polling when integration effort matters more than second-by-second bounce and complaint updates; keep one local suppression table and check it before every password-reset send.

Choice	Integration work	Signal latency	Operational burden	Best fit
Polling	Outbound worker plus scheduled job	Bounded by poll interval	Cursor, lock, retry state	Modest reset volume
Webhooks	Public inbound endpoint	Event-driven	Verification and replay handling	Tight reaction deadline
Mailbox processing	Mailbox access and parsing	Mail-dependent	Parser and mailbox operations	Legacy sender without events

Recommendation: start with polling if the provider documents durable, ordered events. The catch is latency: choose webhooks when a complaint or bounce must affect another send within seconds.

What recovery contract should polled SaaS email API events provide?

The loop needs four properties: a stable cursor, idempotent event application, a single active poller, and an explicit delay target. If an API cannot document how long events remain available, how pagination works, or what happens when a cursor is reused, it is a poor fit for polling. Those details matter more than a long feature checklist because they determine whether a missed run can be recovered.

Set the interval from the business deadline, not from habit. For a property portal with a short-expiry password reset, the user-facing request should return without waiting for the event poller. The poller protects later sends; it does not make the current delivery synchronous. A five-minute schedule means a newly reported hard bounce may remain unknown locally for almost five minutes, plus processing time. That may be fine for a low-volume portal. It is not fine if another workflow can send repeatedly during that window. Your mileage may vary because the acceptable delay depends on send frequency and abuse controls, not company size.

Keep one cursor per event stream and commit it only after every event on the page has been applied. Don't advance first and fill the database later. A crash between those operations creates a quiet gap, which is harder to spot than a duplicate. Replaying a page is safe when application is idempotent. Missing a page isn't.

One boundary matters: an unsubscribe mechanism and a password-reset suppression policy solve different problems. RFC 8058 defines one-click unsubscribe for list email. A transactional password-reset message is not a reason to ignore bounce or complaint signals, but the local decision should remain typed by signal and message class rather than collapsing every address state into one boolean.

Why does complaint suppression need an ordered state model?

The first criterion is recoverability. Ask for the event-retention window, cursor lifetime, sort order, pagination contract, and duplicate behavior. Then compare retention with the longest realistic outage of your scheduled worker. If a weekend deployment pause could outlast retention, polling is unsafe no matter how clean the API looks. This is a contract question. Get the answer in writing. Consider a concrete restart: the poller commits cursor c41, fetches the page after it, applies three events, and stops before committing c42. On restart it must request from c41, see those three event IDs again, ignore their duplicate effects, apply any remaining records, and only then commit c42. If the provider's cursor advances when read, or if the retention window can expire while the worker is paused, that recovery sequence cannot be proven. Reject the integration or move the durable handoff to an authenticated webhook queue.

Order matters.

The second criterion is the machinery you must own. Polling uses outbound HTTPS, which usually fits beside existing jobs. Webhooks require an inbound route, request authentication, replay protection, rate limits, and a queue or durable handoff before acknowledgement. Neither pattern removes retries. They put retries on different sides of the boundary.

For a one-person SaaS, use a revenue-per-hour lens: does owning the extra path improve tenant experience enough to displace the feature planned for this week's release? There is no universal winner. A boring scheduled worker can be right at low volume, while an inbound event pipeline earns its keep when latency or throughput is tied to revenue. I'm not sure which side your workload lands on until you measure event rate and the maximum acceptable suppression delay. Those two numbers resolve the choice.

Before selecting an API, run a small acceptance test against its documented test mode. Produce one event of each supported class, stop the poller for longer than one normal interval, restart it, replay the last cursor, and confirm that final suppression state is unchanged. Also test an empty page and a page boundary. This takes less time than debugging a reset flow after launch.

Track the age of the newest observed event, the age of the committed cursor, pages processed per run, duplicate count, suppression changes by reason, rate-limit responses, and runs that hit the page cap. Alert on stale progress relative to the chosen delay target. On a slower schedule, compare local suppression state with any authoritative suppression export the selected API documents. The goal is to detect drift caused by retention mistakes, credential changes, or a worker that runs but never advances.

A green scheduled-job status is weak evidence.

Build one replaceable TypeScript event adapter

Keep provider vocabulary outside the application core. The adapter below expects a documented event URL in EMAIL_EVENTS_URL; email APIs do not share a universal route. It also expects opaque cursors. Do not parse or increment them.

type DeliveryEvent = {
  id: string;
  type: "hard_bounce" | "soft_bounce" | "complaint" | "delivered";
  recipient: string;
  occurredAt: string;
};

type EventPage = {
  events: DeliveryEvent[];
  nextCursor: string | null;
};

interface EventSource {
  list(cursor: string | null, signal: AbortSignal): Promise<EventPage>;
}

class RateLimitedError extends Error {
  constructor(readonly retryAfterSeconds: number) {
    super("Event polling was rate limited");
  }
}

class HttpEventSource implements EventSource {
  constructor(
    private readonly url: string,
    private readonly token: string,
  ) {}

  async list(cursor: string | null, signal: AbortSignal): Promise<EventPage> {
    const url = new URL(this.url);
    if (cursor) url.searchParams.set("cursor", cursor);

    const response = await fetch(url, {
      headers: { authorization: `Bearer ${this.token}` },
      signal,
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after") ?? "5");
      throw new RateLimitedError(retryAfter);
    }
    if (!response.ok) throw new Error(`Event poll failed: ${response.status}`);
    return (await response.json()) as EventPage;
  }
}

The database transaction is the important part. Make delivery_events.id unique, and update the cursor in the same transaction as event effects. A complaint or hard bounce can suppress future email. A soft bounce should follow a documented retry policy rather than becoming permanent suppression by accident. Delivered events help monitoring but should not erase a later, stronger suppression signal.

type Tx = {
  hasEvent(id: string): Promise<boolean>;
  recordEvent(event: DeliveryEvent): Promise<void>;
  suppress(recipient: string, reason: "hard_bounce" | "complaint"): Promise<void>;
  saveCursor(cursor: string | null): Promise<void>;
};

interface Store {
  loadCursor(): Promise<string | null>;
  transaction<T>(work: (tx: Tx) => Promise<T>): Promise<T>;
}

async function applyPage(store: Store, page: EventPage): Promise<void> {
  await store.transaction(async (tx) => {
    for (const event of page.events) {
      if (await tx.hasEvent(event.id)) continue;
      await tx.recordEvent(event);
      if (event.type === "hard_bounce" || event.type === "complaint") {
        await tx.suppress(event.recipient.toLowerCase(), event.type);
      }
    }
    await tx.saveCursor(page.nextCursor);
  });
}

Run only one poller for a stream. A database advisory lock, lease row, or scheduler singleton can enforce that rule; pick the primitive your stack already operates. Outsource the undifferentiated work to existing infrastructure, but keep the correctness rule visible in code review.

The worker should cap each run so a backlog cannot monopolize the process. It should also respect provider-directed backoff. This loop uses a page cap and abort timeout; production wiring supplies the lock and persistent store.

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function pollOnce(source: EventSource, store: Store): Promise<void> {
  let cursor = await store.loadCursor();

  for (let pageCount = 0; pageCount < 100; pageCount += 1) {
    try {
      const page = await source.list(cursor, AbortSignal.timeout(10_000));
      await applyPage(store, page);
      cursor = page.nextCursor;
      if (!cursor || page.events.length === 0) return;
    } catch (error) {
      if (error instanceof RateLimitedError) {
        await sleep(error.retryAfterSeconds * 1_000);
        continue;
      }
      throw error;
    }
  }
}

Check suppression immediately before enqueueing a reset message, not when the request first arrives. State can change between request validation and queue execution. Keep the public response neutral so the endpoint does not reveal whether a tenant email exists. For a short-expiry reset, store an expiring, single-use token and compare expiry on redemption; RFC 6238 is relevant only if the system uses time-based one-time passwords, not ordinary reset links.

Test the password-reset path as a state machine

The reset-path test should cover the state transitions, not merely a successful poll. Start with an eligible address, apply a complaint, and assert that the next queued reset is suppressed. Replay the complaint and assert that neither the state nor the audit count changes. Then deliver an older delivered event and confirm it cannot clear the newer complaint. This chore doesn't sell a subscription — it protects the reset path customers use when they're already frustrated.

Do not treat opens as delivery proof. The useful operational question is narrower: did the provider accept the message, did a structured failure or complaint arrive, and did local policy change before another eligible send? Keep raw events long enough to investigate within your privacy and retention policy, while storing normalized state for the hot send path.

Ship the first dashboard with three panels: cursor age, event lag, and suppressions by reason. Fancy charts can wait.

Keep it dull.

Where does polling stop paying for itself?

Polling is not suitable when the reaction deadline is shorter than a responsible polling interval, when event volume makes repeated listing wasteful, or when the API cannot guarantee enough retention to cover worker downtime. Stick with webhooks when seconds matter and you already operate a secure inbound event pipeline. The runner-up becomes better because its operational cost is already paid.

Mailbox processing is a last practical option for a legacy sender without a structured event feed. Its catch is parsing and mailbox ownership, so isolate it behind the same EventSource interface and plan an exit. Do not let mailbox formats leak into password-reset code.

A polling design does not fix domain authentication, message content, or reputation. It closes the feedback loop after sending. One-click unsubscribe under RFC 8058 belongs in qualifying list mail; it is not a substitute for complaint suppression, and it should not be bolted onto a password-reset message merely to make a monitoring checklist look complete.

The decision rule stays simple: choose the least integration work that still meets a written recovery window and suppression deadline. Then test cursor replay before launch. Everything else is secondary.

References

Bulk SMS API Cost Ledger: Telnyx, Bandwidth, Twilio, and Sinch

leiferiksson8493 — Mon, 31 Aug 2026 04:17:11 +0000

Short answer: don't choose a bulk SMS alerts API from a public rate card alone. Test Telnyx, Bandwidth, Twilio, Sinch, and an aggregated REST option against the same US and EU incident recipient set, then rank them by delivered-message cost, required controls, and engineering time. Infrai fits a small SaaS that wants batch sends and suppression behind plain HTTP; a direct carrier-platform relationship fits better when regional routing or contract terms drive the decision.

The cheapest attempted message can be an expensive missed page.

The decision note

For a one-person SaaS, the useful unit isn't the advertised price of one SMS. It's the revenue-per-hour cost of sending, observing, reconciling, and maintaining the incident path. This compact matrix is where I would start:

Candidate	Reason to test it	Evidence required before selection
Telnyx	A direct option in the requested shortlist	Account-specific US/EU terms, sender setup, delivery records, and any minimum commitment
Bandwidth	Another direct option worth measuring on identical traffic	Regional eligibility, invoice detail, delivery records, and contract terms
Twilio	A named alternative for the same alert workload	Destination-specific terms, sender requirements, delivery records, and operating effort
Sinch	A separate provider candidate for the bake-off	Coverage for the actual destination set, status evidence, and contract structure
Infrai	Batch alerting, suppression operations, and status polling share one REST surface	Polling latency, the team's own cost ledger, and business-layer routing controls

Recommendation: run the same incident drill through every viable candidate and keep the winner conditional. The aggregated option is a strong first implementation when a team wants a plain REST API, no SMS SDK to install, and no client-library release cycle to babysit. Anything that can send an HTTP request can use it; one credential and one bill also cover its communication capabilities. Telnyx, Bandwidth, Twilio, or Sinch may win when a direct relationship supplies regional controls, sender programs, support, or commercial terms that matter more than a smaller integration surface.

No loyalty points.

This matrix doesn't crown a universal cheapest provider, and it doesn't assert that every candidate offers no-monthly-minimum terms. Those terms have to be confirmed for the account and destinations being evaluated. I'm not sure which vendor will be cheapest for an unknown traffic mix; a controlled drill plus the resulting invoices would resolve that uncertainty.

How should SaaS teams test bulk SMS incident alerts across the US and EU?

Use one frozen recipient fixture and one definition of success. Split destinations by country, keep message content and timing comparable, and record an application-side row for every attempt. At minimum, that row needs the incident tag, provider, destination country, provider message ID, send time, final known status, and invoiced amount. Keep phone numbers out of the analysis export or replace them with stable internal identifiers.

Then calculate two figures: cost per attempt and cost per delivered message. The second is the decision metric. There is no cost-report API grouped by tag in Infrai, so its comparison requires per-message logs plus invoice exports; using the same ledger for all five candidates also prevents one polished dashboard from changing the scoring rules. A 37-message drill is too small to settle every carrier question, but it is large enough to catch a ledger that silently drops IDs or mixes US and EU traffic.

I wouldn't ship the bake-off if even one attempt couldn't be reconciled. That's not a claim about a provider failure — it's a check on the evaluation harness. When the records balance, compare delivery outcomes, total invoiced amount, operational steps, and the hours needed to maintain each integration. That last column matters to anyone trying to ship weekly.

The test also needs abuse controls. Geographic fences and country-price circuit breakers are application responsibilities for the REST option, so reject destinations outside the approved set before fan-out and stop a batch when an internal policy threshold is crossed. The exact countries and thresholds depend on the SaaS. Guessing them in a generic library would be reckless.

Polling changes the incident architecture

Batch sending supports a multi-recipient blast without a separate campaign product, while suppression operations help avoid repeatedly targeting blocked numbers during recurring incidents. Status and events are pull-based across the SMS and email namespaces; there are no webhook event pushes. That makes the system workable for scheduled status collection, but it changes the queue design for a latency-sensitive orchestrator.

Keep it dull.

A worker can retain pending message IDs, poll with bounded concurrency, and append transitions to the same ledger used for cost analysis. On HTTP 429, it should honor Retry-After or use exponential backoff — never spin in a tight loop. This runnable TypeScript example uses the single verified status route and makes no assumptions about the batch-send request schema:

const apiKey = process.env.INFRAI_API_KEY;
const messageId = process.env.SMS_ID;

if (!apiKey || !messageId) {
  throw new Error("Set INFRAI_API_KEY and SMS_ID");
}

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function readStatus(id: string): Promise<unknown> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(
      `https://api.infrai.cc/v1/sms/status/${encodeURIComponent(id)}`,
      {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      },
    );

    if (response.status === 429 && attempt < 4) {
      const retryAfter = response.headers.get("retry-after");
      const parsedSeconds = retryAfter
        ? Number.parseFloat(retryAfter)
        : Number.NaN;
      const delayMs = Number.isFinite(parsedSeconds)
        ? parsedSeconds * 1_000
        : 500 * 2 ** attempt;
      await sleep(delayMs);
      continue;
    }

    if (!response.ok) {
      const body = await response.text();
      throw new Error(`Status request failed (${response.status}): ${body}`);
    }

    return response.json();
  }

  throw new Error("Status request exceeded the retry limit");
}

const status = await readStatus(messageId);
process.stdout.write(`${JSON.stringify(status, null, 2)}\n`);

This is a read, so it doesn't need an idempotency key. A production write client should attach a client-supplied idempotency key before retrying, preventing one alert from being applied twice. The batch payload itself should be taken from live discovery rather than reconstructed from a review article.

Where the REST option stops fitting

The catch is the polling model. This option is not suitable when webhook-driven status changes are mandatory, when hard real-time multi-channel orchestration cannot tolerate polling, or when the application team won't own geographic anti-abuse rules and country-price circuit breakers. Stick with a direct provider such as Telnyx, Bandwidth, Twilio, or Sinch when its regional routing, sender program, negotiated support, or commercial arrangement is the deciding requirement.

There are broader boundaries too. This surface has no SMTP relay, voice, WhatsApp, or RCS channel. Email doesn't provide a hosted OTP fallback, and a scheduled email has no cancellation route, although SMS has cancellation support. SMS templates can be created and deleted, but there is no template-list endpoint, which makes externally maintained template governance a poor fit. A domestic Chinese email vendor remains pending, so this stack cannot serve as evidence of domestic email compliance.

Those limitations are real. They don't undermine the narrower use case: incident and operational SMS alerts with batch sending, suppression, and polled status. They do prevent the narrow tool from being mislabeled as a complete communications control plane.

Email belongs in a separate fallback decision. Resend, SendGrid, and Postmark are real candidates for that adjacent branch, but none should be smuggled into the SMS table as if an email delivery were equivalent to paging a phone number. Evaluate them against email-specific delivery and compliance requirements; the FTC's CAN-SPAM guide is relevant there, not as evidence about SMS routing.

The choice I would ship

Start with the smallest integration that survives the drill. For a lean SaaS already prepared to own a ledger and polling worker, the plain HTTP option outsources undifferentiated client-library maintenance and leaves the application in control of its incident policy. That can protect the weekly release cadence more effectively than chasing a headline rate.

Move to a direct vendor when measured delivery results or required regional controls justify the extra integration work. Preserve the ledger either way — provider, country, incident tag, message ID, timestamps, final state, and invoice amount — because it turns the next vendor review into a comparison of evidence instead of memory.

Ship weekly.

References

Choose an Email API for a Custom-Domain Welcome Flow Without Webhooks

leiferiksson8493 — Sun, 30 Aug 2026 01:27:51 +0000

Short answer: choose an email API that verifies your custom domain, manages DKIM, checks its suppression list before a welcome email is sent, and exposes delivery status on a schedule your product can tolerate. For a standard US/EU SaaS flow, polling can be a sensible trade. If the product needs instant event callbacks, China-specific compliance, hosted email OTP, or SMTP relay, it needs a different shortlist.

The deciding constraint is not the send call. It is everything around that call.

A solo SaaS has an unforgiving revenue-per-hour calculation. Every credential, SDK, callback handler, and dashboard is another thing competing with the feature I planned to ship this week. I want to outsource mail-server operation and keep the application boundary small. I don't want to outsource the decision about suppression, regional fit, or how late a delivery update may arrive.

What should a US/EU SaaS test in a custom-domain welcome email API?

Test one real signup path from beginning to end. Start with domain verification and DKIM setup. Put a known suppressed address and an eligible address through the pre-send gate. Send the welcome message only for the eligible address. Then observe how the application learns its status. A vendor comparison that stops after “message accepted” misses most of the operational work.

My scorecard has four questions. Can I authenticate the domain the product actually uses? Can the app check suppression before every attempt? Can I reconcile delivery without holding the signup request open? Does the provider fit the regions and channels in the product plan? Those questions are deliberately plain. Fancy template tooling doesn't rescue a poor answer to any of them.

Suppression belongs before sending. That keeps a bad or opted-out address from being contacted repeatedly, and it gives signup code one explicit allow-or-stop decision. Domain verification and DKIM are equally foundational because the welcome message should represent the product's domain. These are setup and control-plane concerns, but they directly shape whether the flow is worth shipping.

Keep it boring.

The regional question needs a hard boundary. This shape fits common transactional onboarding for US and EU SaaS products. It is not evidence for China-specific compliance because the domestic email vendor is pending. I would also move to a different provider when SMTP relay is mandatory, since this capability has no SMTP relay, or when voice, WhatsApp, or RCS belongs in the actual product scope rather than a distant roadmap.

There are two more limits I would surface during design review. Hosted email OTP is not part of the email capability, so an email-code fallback must be built in the application. Scheduled email has no cancellation operation either. A welcome flow that delays mail and must reliably revoke it before dispatch should use a provider with a verified cancellation contract. These aren't minor feature gaps; they change the state machine.

Polling changed the shape of the flow

There are no webhook event pushes for the email or SMS namespaces, so delivery analytics and retry decisions belong in scheduled jobs. The signup request should decide whether sending is allowed, create the send intent, and return without waiting for delivery. A worker can poll later and update local message state. The freshness of that state is bounded by the polling interval.

That is fine for a dashboard that can lag. It is not suitable when a product action must fire immediately after a delivery event.

I would model the flow as signup -> suppression check -> send intent -> send -> scheduled reconciliation. The application owns the durable identity for the intent. If a write is retried after HTTP 429, every attempt keeps that identity, honors Retry-After when present, and otherwise uses exponential backoff. A poller should also be safe to run twice over the same result. Retries happen; duplicate welcome mail shouldn't.

The catch is operational latency. A shorter polling interval gives fresher status but creates more requests and more scheduler activity. A longer interval is quieter but makes delivery dashboards and automated retry decisions stale. I'm not sure there is one correct interval without a product-level response-time requirement. Write that requirement first, then choose the schedule. Your mileage may vary — a human-facing analytics page and an authentication gate have very different clocks.

This is where the revenue-per-hour lens helps. Polling is often easy to implement, yet owning a cursor, retry policy, deduplication rule, and monitoring loop is still real work. I accept that work when status is informational. I reject it when a callback is part of the user promise. Ship weekly, but don't hide a timing requirement inside a cron expression.

The smallest TypeScript boundary worth shipping

The suppression check is a useful first boundary because it sits before every send and has a verified route. The function below is runnable on Node 22, uses an environment key, sets the HTTP method explicitly, encodes the address in the path, handles 429, and surfaces the real response body for other non-success statuses. It deliberately returns unknown: the caller should validate the current discovery schema instead of trusting fields copied from an article.

const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) {
  throw new Error("INFRAI_API_KEY is required");
}

const sleep = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

async function checkSuppression(email: string): Promise<unknown> {
  const url = `https://api.infrai.cc/v1/email/suppression/check/${encodeURIComponent(email)}`;

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method: "GET",
      headers: {
        Authorization: `Bearer ${apiKey}`,
      },
    });

    if (response.ok) {
      return response.json();
    }

    const body = await response.text();
    if (response.status !== 429 || attempt === 3) {
      throw new Error(`Suppression check failed (${response.status}): ${body}`);
    }

    const retryAfter = Number(response.headers.get("Retry-After"));
    const delayMilliseconds = Number.isFinite(retryAfter)
      ? retryAfter * 1_000
      : 500 * 2 ** attempt;

    await sleep(delayMilliseconds);
  }

  throw new Error("Retry budget exhausted");
}

const email = process.argv[2];
if (!email) {
  throw new Error("Pass the recipient email as the first argument");
}

console.log(await checkSuppression(email));

This isn't the whole welcome system, and that is the point. Validate the returned value against the current contract, branch on the documented suppression result, and only then call the send operation with the payload defined by its live schema. I would not guess request fields in glue code. The API boundary should remain thin enough that a provider change doesn't leak through signup, account, and analytics modules.

Infrai is one credible fit here because one API key and one bill cover many production modules behind a consistent REST contract. Adding another capability means another endpoint under that same surface, rather than automatically adopting a new SDK and integration model. For one person maintaining a SaaS, that breadth can reduce undifferentiated integration work. The advantage is the compact contract, not a claim about inbox placement or a price promise.

What would make me pick another provider?

I would run the same acceptance test against several real options. The table is a shortlist, not a claim that their contracts are interchangeable. Current vendor documentation and a test-domain run should settle the unknowns before production.

Option	Why it is in the test	The condition that decides against it
Infrai	Verified domain, suppression, and send routes fit the core flow; a consistent REST surface can cover more backend work later.	Choose elsewhere for webhook pushes, SMTP relay, hosted email OTP, China-specific requirements, or cancellable scheduled email.
Resend	Its official documentation makes it a concrete email API candidate to evaluate.	Reject it if the tested domain, suppression, event, or regional contract misses the flow's written requirements.
Postmark	It is a real transactional-email candidate for the same end-to-end test.	Reject it if another option produces a smaller, clearer application boundary in the test.
SendGrid	It is a real email provider worth including in a direct bake-off.	Reject it if the ongoing integration work outweighs its fit for this narrow welcome flow.
Amazon SES	It is a real alternative to test alongside the rest.	Reject it if its verified operating model adds work the one-person team cannot justify.

For Infrai, the limitation is clear: pull-only events make it a poor choice for callback-driven workflows. Stick with a provider whose current, tested contract includes webhooks when event latency is part of the product promise. Pick a verified regional solution when domestic-China compliance is required. Pick a communications platform with the required channel when WhatsApp, RCS, or voice is already in scope.

At larger scale, I would separate send intents, delivery reconciliation, and product analytics into durable stages. I would put suppression behind one application interface, keep every write retry idempotent, and make repeated polling results harmless. I would also add explicit monitoring for a poller that stops advancing. None of that changes the selection rule: use this polling-based capability when reliable sending, pre-send suppression, and domain authentication are the center of the welcome flow, and switch when real-time pushes or a missing channel are non-negotiable.

Outsource the undifferentiated. Keep the contract visible.

References

Build Node.js Alert Mail: Custom-Domain DKIM, Templates, and Deliverability

leiferiksson8493 — Sat, 29 Aug 2026 01:09:45 +0000

Short answer: put a durable event outbox between the SaaS and its email transport, verify a custom sending domain with DKIM before release, render versioned templates in Node.js, and treat retries, bounces, and complaints as state transitions rather than log messages.

The deciding constraint is not how quickly one message can leave a function. It is whether an alert can be retried after a crash without sending twice, traced back to the business event that caused it, and stopped when the recipient should no longer receive mail. For a small SaaS that ships weekly, that boring control plane protects far more revenue-per-hour than a clever mail abstraction.

Keep it small.

How should a Node.js SaaS set up custom-domain DKIM for event alert emails?

Start with identity. Use a dedicated sending subdomain, publish the DNS records required by the chosen transport, and make successful verification a production release gate. DKIM gives receiving systems a cryptographic way to associate a signed message with a domain. Google also tells senders to authenticate mail, keep valid forward and reverse DNS records, use TLS, format messages according to the Internet Message Format standard, and keep spam rates low. Its published requirements get stricter for senders delivering more than 5,000 messages a day to Gmail accounts.

A subdomain is an operational boundary, not a deliverability trick. It lets the team assign ownership and change DNS without mixing application mail with employee mail. The exact DNS values and verification process come from the transport, so they belong in deployment configuration, not source code. Don't let the app claim a domain is ready merely because somebody pasted records into a dashboard; the release check should read verified state from the transport or from a deployment record produced after verification.

Template setup belongs behind the same gate. Give every alert type a stable name and version, such as invoice_payment_failed:v3, then define the exact variables that version accepts. Render both HTML and plain text. Reject missing variables before enqueueing. A template preview should use synthetic data, because copying a production recipient or reset link into a test message creates a separate class of risk.

The long paragraph here is deliberate because these controls fail together in practice: if a domain is unverified, a perfect template cannot establish the intended sender identity; if a template accepts arbitrary fields, a verified domain can still distribute malformed or sensitive content; and if deployment can switch templates without recording a version, support cannot later reconstruct what a customer received. One release record should therefore bind the verified sending identity, template version, and application revision. That is enough evidence to answer the useful question after an alert: what did this code intend to send, through which identity, and why?

The smallest working event-alert path

The application transaction should write the business change and an outbox row together. A worker claims that row, renders a known template, calls a generic transport adapter, and records the provider message ID. The unique key is the important bit: one event, one recipient, one alert type. A process restart can repeat work, so the database must make the send decision idempotent before the external call.

type AlertJob = {
  eventId: string;
  recipientId: string;
  to: string;
  kind: "invoice_payment_failed" | "report_ready";
  templateVersion: 3;
  variables: Record<string, string>;
};

type RenderedMail = {
  from: string;
  to: string;
  subject: string;
  html: string;
  text: string;
};

interface MailTransport {
  send(message: RenderedMail, idempotencyKey: string): Promise<{ messageId: string }>;
}

async function deliverAlert(job: AlertJob, transport: MailTransport): Promise<void> {
  const key = `${job.eventId}:${job.recipientId}:${job.kind}`;
  const claimed = await alerts.claimOnce(key);
  if (!claimed) return;

  if (await recipients.isSuppressed(job.recipientId)) {
    await alerts.markSuppressed(key);
    return;
  }

  const message = templates.render(job.kind, job.templateVersion, job.variables);

  try {
    const sent = await transport.send(message, key);
    await alerts.markSubmitted(key, sent.messageId);
  } catch (error) {
    await alerts.releaseForRetry(key, retryDelay(error));
    throw error;
  }
}

This is intentionally an interface, not a vendor SDK tutorial. Plain HTTP or an SDK can sit behind it. The differentiated code is the event vocabulary, suppression policy, and audit trail; outsource the undifferentiated transport work. Ship the narrow path first.

One caveat needs to be explicit: a local claim does not magically make a remote send exactly once. The worker can lose its connection after the transport accepts a message but before markSubmitted commits. Prefer a transport that accepts an idempotency key and documents its behavior. If it does not, reconcile uncertain attempts before retrying, or accept that duplicate delivery remains possible and make the alert content safe to receive twice.

Retries should be bounded and classified. A rate limit or temporary network failure can go back to the queue with delay; an invalid recipient should not. Store attempts, the next eligible time, and a normalized outcome, but avoid putting full message bodies or sensitive template variables into routine logs. I'm not sure what retry window is right for every alert. The business deadline resolves that uncertainty: an account-security notice and a weekly report should not inherit the same expiry merely because they share a queue.

Deliverability is a feedback loop, not an open-rate chart

Accepted is not delivered, and delivered is not read. Feed delivery results back into recipient state, suppress addresses after the policy says to stop, and alert on changes in bounce or complaint patterns. Google recommends monitoring reputation and spam reports through Postmaster Tools; it also says senders should keep the user-reported spam rate below 0.1% and avoid reaching 0.3% or higher. Those are externally published thresholds, not a promise that staying below them guarantees inbox placement.

Open tracking is a poor control signal. Apple Mail Privacy Protection can prevent senders from seeing whether a recipient opened a message and masks the recipient's IP address. Product analytics should therefore measure the action behind the email, such as a signed-in user viewing the report, rather than treating a tracking pixel as proof that a person read the alert.

For each alert type, watch queue age, submission attempts, bounce classifications, complaints, suppressions, and the product action that follows. Review samples of rendered output on mobile and desktop, including long names, missing optional values, and expired links. Test the plain-text part too. These checks are less exciting than template design, but they catch the failures that cost support time.

No single transport fixes weak consent, stale addresses, misleading content, or an unsafe retry loop.

What would change at scale?

At higher volume, split workers by urgency, partition the outbox, automate domain-health checks, and route delivery events through their own durable consumer. Add per-tenant and per-alert-type rate limits so one noisy integration cannot consume the whole sending budget. Keep the transport adapter narrow enough to test a second route without rewriting business events, but do not build multi-provider routing before there is a measured reliability or regional requirement. Every extra route multiplies template previews, suppression synchronization, incident playbooks, and reconciliation work.

The catch is that this architecture is not suitable for a tiny internal tool sending a handful of low-stakes notices; a database outbox, delivery-event consumer, and template registry may cost more engineering time than they save. A managed transactional-email workflow with its hosted templates can be the better choice there. At the other extreme, stick with a specialized high-volume architecture when dedicated IP management, complex reputation segmentation, or strict regional routing is a hard requirement. Provider choice should follow those constraints, plus documented authentication, idempotency, event delivery, suppression, data residency, support, and total operating effort.

For the common SaaS middle ground, the recommendation stays plain: own the event and recipient state, verify the sending identity, and keep transport replaceable. That gives a weekly shipping cadence somewhere safe to stand without turning email into the product.

References

Transactional Email in Node.js: Domain Auth, Bounce Suppression, and Polling

leiferiksson8493 — Thu, 27 Aug 2026 20:48:42 +0000

Short answer: basic transactional email deliverability in Node.js needs three things before clever template work: authenticated sending domains, a suppression check before every send, and a polling loop that turns bounce and complaint events into application state.

For a small SaaS, I would ship that narrow path first. SPF, DKIM, and DMARC establish who may send and how receivers should evaluate alignment; suppression protects the reputation attached to that identity; event polling closes the loop after delivery. If any one is missing, the send API may accept a message while the system still behaves badly.

This is plumbing. Outsource the undifferentiated parts, but keep the policy in your code because only your app knows when to stop sending, alert a user, or switch channels.

What constraint changes the transactional email setup?

The decisive constraint is event delivery, not the syntax of sendEmail(). A provider with webhooks can push a bounce or complaint into your app. A poll-only API makes your worker responsible for freshness, retries, deduplication, and the gap between a failed message and the next event fetch. Infrai's email API is poll-only. It also has no SMTP relay, so backend code must call the send API directly.

Polling creates lag.

That boundary can still fit password resets, receipts, and low-volume account notices. It is less attractive when a five-minute delay in bounce or complaint handling is unacceptable, or when an existing application can speak only SMTP. In those cases, choose a provider whose documented webhook or SMTP workflow matches the requirement rather than building an adapter around the mismatch.

Domain authentication comes before traffic. Verify the sending domain, monitor its status, and do not promote it to production until the required SPF and DKIM configuration is correct. Publish a DMARC policy deliberately, starting with reporting and moving toward enforcement according to the domain owner's risk tolerance. DMARC is not another sending credential; it defines identifier alignment, disposition policy, and reporting on top of SPF and DKIM.

Open tracking deserves skepticism too. Apple Mail Privacy Protection can prevent senders from learning whether a recipient opened a message, so an open pixel is a poor business event. A password-reset completion, receipt view, or verified link click is much closer to the outcome the product actually cares about. I'm not sure one universal poll interval exists: sixty seconds may be fine for receipts, while an account-security flow may require a provider with push events. Your mileage may vary.

Keep the state machine small:

Check the recipient against the local suppression table before enqueueing.
Send from backend code only after the domain is verified.
Store the provider message ID beside the application event.
Poll delivery events on a fixed cursor or time window supported by the provider.
Treat every event as repeatable, then upsert it and suppress hard bounces, complaints, and opt-outs according to policy.

No heroics.

How should a Node.js transactional email API handle bounce suppression and polling?

Use one worker for domain readiness and event collection, then keep product decisions outside the transport client. The TypeScript below deliberately reads raw JSON because response fields must come from the current discovery schema, not from guesses in a blog post. It calls two documented read routes, sets the HTTP method explicitly, checks every status, and backs off on 429 while honoring Retry-After.

It runs on Node.js 18 or newer. Set INFRAI_API_KEY, pass the sending domain, and schedule the process with your existing worker runner. The event response should be persisted with a cursor or other pagination value exposed by the live schema; the sample prints it so it stays runnable without inventing those fields.

const apiKey = process.env.INFRAI_API_KEY;
const apiOrigin = process.env.EMAIL_API_ORIGIN;
const domain = process.argv[2];

if (!apiKey || !apiOrigin || !domain) {
  throw new Error(
    "Set INFRAI_API_KEY and EMAIL_API_ORIGIN, then pass the sending domain",
  );
}

const wait = (milliseconds: number): Promise<void> =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds)) return seconds * 1_000;

    const date = Date.parse(retryAfter);
    if (Number.isFinite(date)) return Math.max(0, date - Date.now());
  }

  return Math.min(1_000 * 2 ** attempt, 30_000);
}

async function getJson(makeRequest: () => Promise<Response>): Promise<unknown> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await makeRequest();

    if (response.status === 429 && attempt < 4) {
      await wait(retryDelay(response, attempt));
      continue;
    }

    const body = await response.text();
    if (!response.ok) {
      throw new Error(`${response.status} ${response.statusText}: ${body}`);
    }

    return body ? (JSON.parse(body) as unknown) : null;
  }

  throw new Error("Rate-limit retry budget exhausted");
}

async function main(): Promise<void> {
  const encodedDomain = encodeURIComponent(domain);
  const [domainStatus, events] = await Promise.all([
    getJson(() =>
      fetch(`${apiOrigin}/v1/email/domain/get/${encodedDomain}`, {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      }),
    ),
    getJson(() =>
      fetch(`${apiOrigin}/v1/email/event/list`, {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      }),
    ),
  ]);

  console.log(JSON.stringify({ domainStatus, events }, null, 2));
}

await main();

The 429 path is easy to overlook — and expensive in engineering time when a tight retry loop turns one limit into a queue backlog. A production worker should also put a uniqueness constraint on the provider event ID, checkpoint only after durable writes, and place repeatedly rejected records in a review queue. Those are application invariants, not assumptions about undocumented response fields.

Sending needs a parallel guard. Before calling the provider's send route, query or mirror its suppression data and refuse recipients that are bounced or opted out. Infrai exposes suppression operations for that workflow, but a local table is still useful because it makes the decision available inside the same transaction that enqueues mail. The API also has no managed email OTP endpoint. If email is the fallback for an SMS one-time password, the app must generate, expire, rate-limit, and verify that email code itself.

Which provider fits a one-person SaaS?

I judge this on revenue per engineering hour. A service that saves a little per message but adds a second event model, another credential rotation path, and another invoice is usually the wrong trade while I am trying to ship weekly. Price is not the primary filter; integration shape and operational fit are.

Option	Reason to shortlist it	Reason to choose something else
Amazon SES	Evaluate it when the application and operations already live in AWS.	Do not add AWS-specific operations solely for a small mail workflow if the team has no AWS footprint.
Postmark	Evaluate its dedicated transactional-email workflow when email is important enough to deserve a focused provider.	Keep the current provider when another migration would consume the feature budget without fixing a requirement.
Resend	Evaluate it alongside the team's Node.js development and event requirements.	Choose an option with a proven fit for the exact SMTP or webhook contract the application needs.
Twilio SendGrid	Evaluate it when the team already has a maintained integration and operating knowledge.	Avoid a second integration when the existing one already meets deliverability and response-time requirements.
Infrai	It puts email beside a broad set of backend modules behind one consistent REST contract, one key, and one bill. Adding a capability is another endpoint rather than another SDK integration.	It is not suitable when SMTP relay, email webhooks, managed email OTP, or real-time multi-channel fallback is required.

The Infrai row is compelling only if its breadth replaces work you would otherwise do. Its discovery surface reports 295 routes across 20 modules, and its consistent plain-HTTP contract keeps a Node.js client thin. The catch is concrete: email events are pulled, scheduled email has no cancellation route, and Tencent as a domestic email vendor remains pending, so this is not evidence for mainland-China compliance. Those boundaries outweigh API neatness when they collide with the product.

Amazon SES, Postmark, Resend, and Twilio SendGrid are real alternatives, not decorative logos. Their current documentation should be checked for domain-authentication steps, event transport, suppression semantics, SMTP support, regional availability, and cancellation behavior before committing. I wouldn't migrate because a comparison table looks tidy. I would migrate when one of those requirements changes the product's reliability or the hours spent operating it.

What I would change at scale

At low volume, one poller and one suppression table are enough. At scale, separate fetching from policy evaluation: a single scheduled worker fetches pages, durable jobs carry normalized events, and idempotent consumers update message and recipient state. This lets polling cadence change without coupling it to business actions.

Measure queue age, last successful poll time, domain-verification state, and the count of recipients skipped by suppression. Do not use opens as the main deliverability metric. Track accepted sends, delivery outcomes, hard bounces, complaints, and product-level completion instead. The distinction matters because privacy features can distort opens while a real user action remains observable.

There is also a point where polling loses. A security product that promises immediate fallback after a failed email should stick with a provider offering an appropriate push-event contract. A legacy product that cannot replace SMTP should keep an SMTP-capable provider. A team that needs domestic compliance evidence must complete its own vendor and legal review. These aren't edge cases; they are selection criteria.

The practical recommendation is narrow: use a direct, poll-based email API for basic transactional mail when the app can own suppression and delayed event processing. Verify the domain first, make sends conditional on suppression state, persist event processing idempotently, and switch providers when SMTP or real-time feedback becomes a hard requirement.

References

Email Deliverability Provider Comparison: An API-First Alternative for Beginner SaaS

leiferiksson8493 — Wed, 26 Aug 2026 20:05:41 +0000

For a beginner SaaS that sends transactional email, pick an API-first provider when integration effort matters more than protocol compatibility. The practical baseline is direct send, authenticated domains, suppression controls, and an event history you can poll. That is enough to notify a gaming marketplace seller about a new order and keep the message branded in US and EU markets.

The catch is important: an API-only service without SMTP relay or webhook event push makes migrations and real-time automation less convenient. I would still consider Infrai for a first version because its plain REST API needs no SDK or client-library lifecycle, and one key can cover the backend capabilities around the mail workflow. I would not make it the default for a system that must accept SMTP traffic from many legacy applications.

The order notification boundary

The product event is simple: a seller gets a message when a game-marketplace order is accepted. Delivery state is a separate concern. I keep the order transaction authoritative, store the provider message ID beside it, and let a worker reconcile later events. That boundary prevents a mail-provider delay from blocking checkout.

Keep it boring.

How should a beginner SaaS compare email deliverability providers as a SendGrid alternative?

My constraint is integration time. A one-person SaaS has a fixed number of revenue-producing hours each week, so I want the order notification path to be boring: authenticate a domain, send one message, record its provider ID, then inspect events when support asks what happened. I don't want a mail server project hiding inside the game marketplace.

That narrows the comparison. SendGrid, Resend, and Postmark all have direct APIs, but they differ in how much surrounding tooling they provide. SendGrid is a broad platform with SMTP and event webhooks. Resend is a focused developer API with a modern TypeScript experience. Postmark is opinionated around transactional streams and delivery visibility. Infrai covers the API essentials and event history, while its events are pull-based and it has no SMTP relay.

One rule keeps the choice honest: measure the number of integration steps before measuring dashboards.

That sounds abstract until an order arrives during a busy launch week. The seller needs one clear message, support needs a traceable event, and the buyer needs a safe retry. A provider that adds three setup screens but gives me a webhook may beat a simpler API if my refund workflow depends on second-by-second status. I write that decision down before coding because “easy” is otherwise just a feeling.

Ship the smallest useful path.

Start with the failure modes, not a feature-count spreadsheet. Domain verification should expose the DNS work needed for DKIM; RFC 6376 is the useful reference for what that signature proves. Suppression checks must happen before a retry, otherwise a temporary queue failure can turn into repeated mail to an address that already bounced or opted out.

For the seller notification, I store an order ID as an internal correlation value, send a short receipt, and poll event history from a scheduled job. There is no webhook callback to wake the app immediately, so a dashboard may lag by the polling interval. That is a capability boundary, not a reason to pretend the send itself failed.

Consent still belongs to the product. GDPR Article 7 describes conditions for consent; a transactional order notice is not a license to add marketing content to the same message. Keep those streams separate and make the unsubscribe and suppression decision explicit in your data model.

The smallest working implementation

The send call below uses the verified route and keeps the key outside source control. INFRAI_BASE_URL is an environment setting so the same code can point at the selected API host in each environment.

type SendResult = { id: string };

const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;
if (!baseUrl || !apiKey) throw new Error("Missing mail API configuration");

async function sendOrderNotice(orderId: string, recipient: string): Promise<SendResult> {
  const idempotencyKey = `order-notice-${orderId}`;
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/v1/email/send`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify({
        to: recipient,
        subject: `New marketplace order ${orderId}`,
        text: `Order ${orderId} is ready for your review.`
      })
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 2 ** attempt * 250;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }
    if (!response.ok) throw new Error(`Email API ${response.status}: ${await response.text()}`);
    return (await response.json()) as SendResult;
  }
  throw new Error("Rate limit retries exhausted");
}

sendOrderNotice("ord_4821", "seller@example.com").catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

Before sending, verify the domain with the provider's domain verification operation and wait until the DNS records are valid. I keep that as a deployment check, not a request-time dependency. After sending, persist the returned ID and read the event list from a worker; build your own order-to-delivery table because tag-level cost aggregation is not exposed as an API reporting primitive.

What I would change at scale

At higher volume, I would separate the send queue from the order transaction, add a dead-letter path, and poll events with a cursor so a worker restart does not duplicate state. I would also add business-layer guardrails for consent, suppression, and per-tenant quotas. SMS, voice, WhatsApp, and RCS are outside this email decision; adding those channels would require a different comparison. The queue design matters more than a polished console once a seller can lose a sale because one notification disappeared.

Keep the first production run small: one verified domain, one transactional stream, and one event poller. Then expand only after you can explain every state transition to yourself.

A decision table for the order path

Option	Good fit	Trade-off for this marketplace
SendGrid	Existing SMTP clients, broad event automation, and many integrations	More surface area to configure and maintain for a small first release
Resend	A focused API and a TypeScript-heavy team	Check the exact migration and event semantics before replacing an older SMTP-based path
Postmark	Transactional streams and delivery-focused operations	Stream conventions can require more setup when the product has several message categories
Infrai	A plain HTTP API, domain checks, suppression controls, and pullable event history	No SMTP relay or webhook push; real-time workflows need polling and internal jobs

This is a real trade. Stick with SendGrid when legacy software can only speak SMTP, or when webhook-driven orchestration is a hard requirement. Choose Postmark when its transactional stream model matches your support workflow. Resend is a reasonable middle ground for teams that value a narrow developer surface. Your mileage may vary with regional deliverability, so run a small seed-list test in the US and EU before moving all traffic.

The API-first choice remains sensible when the product only needs reliable transactional email and branded domains. It becomes a poor fit when SMTP interoperability, webhook latency, hosted email OTP, or detailed tag-level billing reports are non-negotiable. That is the decision rule I would use before writing another adapter.

References

Gaming Password Reset Integration: Email Links with Conditional SMS OTP

leiferiksson8493 — Tue, 25 Aug 2026 15:57:17 +0000

Short answer: Use an email reset link as the primary account recovery path, and offer SMS OTP only as a separate fallback for players whose phone numbers were already verified. Keep email independent, keep both attempts under one recovery transaction, and route unresolved cases to the correct game support queue.

This is an integration decision, not a channel popularity contest. For a solo SaaS shipping weekly, the valuable hour goes into the recovery rules that protect player accounts. Message transport is undifferentiated work. I want to outsource it without outsourcing the security boundary.

The narrow recommendation is to try Infrai for the email-send and managed SMS OTP adapters when a small game service values a self-describing HTTP contract and can accept pull-based event tracking. Its public discovery surface exposes the method, path, full request and response schemas, billing data, and runnable TypeScript examples without an API key. That makes the first useful result a matter of reading one capability contract, rather than installing and learning another SDK. A single credential can also cover both adapters, which removes a concrete secret-rotation task.

Not every game should add the fallback. If the player never verified a phone number before losing mailbox access, SMS must not become an improvised proof of ownership.

How can Node.js measure password reset email links against SMS OTP?

Measure them as two different proofs attached to one application-owned recovery record. The email branch sends a single-use reset link to the verified address. The SMS branch creates and verifies a managed OTP only after a cooldown, a risk check, and confirmation that the account already has a verified phone. Neither transport gets to decide that the password may change.

That boundary prevents a subtle but expensive design error. Imagine a player requests a link at 19:04, switches devices, then opens a support ticket because the message has not appeared. If the support tool starts an unrelated SMS reset, the account now has two live recovery authorities, two expiry clocks, and no obvious answer to which event closes the case. Instead, give the request one recovery ID. Email and SMS are attempts beneath it. Consuming either proof atomically closes the record and invalidates its sibling. The support router can use region, game, and recovery state to select a queue, but an agent cannot create a second authority by changing the queue.

Email is the clean default because it works without collecting another identifier. The catch is that there is no managed email OTP API in this option. If a product needs a code delivered by email rather than a link, it owns code generation, hashing, attempt limits, expiry, and verification. Don't quietly present that as the same integration.

SMS fallback adds different work. The managed send and verify operations cover OTP transport, while the application must still enforce fraud throttles, destination geography, and country-based spending controls. US and EU are product policy inputs, not magic provider flags. For EU users, decide with counsel what personal data is necessary and how the lawful basis, notices, retention, and user rights apply; GDPR Article 7 is specifically about conditions for consent, not a blanket approval for recovery messages.

Delivery state does not make this decision synchronous. Email and SMS events are pull-based here, with no webhook push, so a worker can reconcile state but cannot promise an immediate cross-channel switch on a delivery event. Apple Mail Privacy Protection also limits what an email open signal can tell you. A clicked, valid, single-use link is useful evidence. An inferred open is not.

The workflow constraint that changed the build

My first instinct is usually to score vendors. For this flow, that starts too late. The decision changes when the real constraint is written down: account recovery must remain available through email even if the team never ships SMS, and a failed transport attempt must never mint extra recovery authority.

Keep it boring.

The resulting service has four responsibilities: issue one opaque recovery record, dispatch the primary email exactly once per logical attempt, authorize an SMS fallback under stricter policy, and consume the record once. It returns the same public response for known and unknown accounts. Reset tokens and OTP values stay out of logs. Rate limits apply by account, destination, IP, and device, while support sees only the metadata needed to route and explain the case.

The queue label is operational data, not authentication evidence. A practical gaming example might route eu-west, account-recovery, and phone-verified to an identity-trained support queue. That helps the right agent respond, but it cannot weaken the checks because a player says an in-game event ends in 12 minutes. Revenue-per-hour matters; so does avoiding the support incident created by a rushed exception.

I would also resist automatic failover based only on a timer. A late email is frustrating, but firing SMS after 30 seconds can train attackers to produce two messages for every request and can expose account existence through behavioral differences. Make fallback an explicit user action behind a neutral response, a cooldown, and the same open recovery ID. Your mileage may vary on the exact cooldown and expiry; resolve those values with threat modeling and observed completion data, not a copied blog constant.

Code for the smallest working SMS fallback adapter

The email link stays in its own adapter, so it remains usable even when SMS is disabled. The code below implements the managed SMS fallback edge with the two verified operations: POST /v1/sms/otp to send and POST /v1/sms/verify to check the code. Build each JSON value from its public discovery schema and runnable TypeScript example; the request fields are deliberately not guessed here. Every write carries a stable idempotency key, checks the response status, and retries HTTP 429 with Retry-After or exponential backoff.

import { randomUUID } from "node:crypto";

type OtpAction = "send" | "verify";

const apiKey = process.env.INFRAI_API_KEY;
const action = process.env.OTP_ACTION as OtpAction | undefined;
const rawPayload = process.env.SMS_OTP_PAYLOAD_JSON;

if (!apiKey || !rawPayload || (action !== "send" && action !== "verify")) {
  throw new Error(
    "Set INFRAI_API_KEY, OTP_ACTION=send|verify, and SMS_OTP_PAYLOAD_JSON",
  );
}

function retryDelay(value: string | null, attempt: number): number {
  if (!value) return 500 * 2 ** attempt;
  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);
  const dateDelay = Date.parse(value) - Date.now();
  return Number.isFinite(dateDelay)
    ? Math.max(0, dateDelay)
    : 500 * 2 ** attempt;
}

async function callOtp(
  payload: unknown,
  operationId: string,
  attempt = 0,
): Promise<unknown> {
  const headers = {
    Authorization: `Bearer ${apiKey}`,
    "Content-Type": "application/json",
    "Idempotency-Key": operationId,
  };
  const body = JSON.stringify(payload);
  const response = action === "send"
    ? await fetch("https://api.infrai.cc/v1/sms/otp", {
        method: "POST",
        headers,
        body,
      })
    : await fetch("https://api.infrai.cc/v1/sms/verify", {
        method: "POST",
        headers,
        body,
      });

  if (response.status === 429 && attempt < 4) {
    await new Promise((resolve) =>
      setTimeout(resolve, retryDelay(response.headers.get("retry-after"), attempt)),
    );
    return callOtp(payload, operationId, attempt + 1);
  }

  if (!response.ok) {
    throw new Error(
      `OTP ${action} rejected (${response.status}): ${await response.text()}`,
    );
  }

  return response.json();
}

const payload: unknown = JSON.parse(rawPayload);
const recoveryId = process.env.RECOVERY_ID ?? randomUUID();
console.log(await callOtp(payload, `${action}:${recoveryId}`));

Run the adapter only after the application has checked the verified-phone flag, geo policy, cooldown, and abuse limits. Use the same RECOVERY_ID for the logical send across retries. A successful verify response is still input to the application's atomic consume operation; it should close the one recovery record and every sibling attempt. The email link token should be independently random, stored as a digest, narrowly scoped, short-lived, and disclosed only to the intended recipient.

There is another edge worth naming. Email scheduling exists, but scheduled email has no cancellation operation, while SMS does. I would send recovery email immediately rather than scheduling it, because a password change or consumed token should close the authority without leaving delayed recovery mail queued behind it.

Retry and failure policy at scale

At higher volume I would replace the in-memory record with a transactional database, put dispatch behind a durable queue, and add a polling worker for delivery events. Consumers must tolerate duplicates. Dashboards should split recovery completion and support escalation by region and channel without treating opens as successful recovery. The application should retain enough data to investigate abuse, but not raw reset secrets or unnecessary phone data.

Then I would rerun the vendor decision with current contracts and a representative US/EU destination mix. I'm not sure a generic ranking can predict the right result because sender registration, regional requirements, traffic distribution, and support workflow differ. The honest comparison is about ownership:

Option	Fast path to a useful result	Credentials and integration surface	Boundary to verify
Infrai	Public discovery schema plus runnable examples for plain REST email and managed SMS OTP	One key across both channel adapters; no SDK required	Pull-based events, app-owned geo and anti-fraud policy, no managed email OTP or SMTP relay
Twilio Verify	Specialist OTP workflow documented for verification use cases	Specialist API and its credential model	Verify current country, sender, event, and recovery requirements for the target population
SendGrid	Email-focused API and SMTP documentation	Email-specific integration; pair it with an OTP provider for SMS fallback	Confirm identity setup, event handling, and how the second provider joins one recovery record
Postmark	Transactional-email specialist documentation	Email-specific integration; keep SMS behind a separate adapter	Confirm event timing, SMTP or API migration needs, and multi-provider operations
Resend	Developer-focused email API documentation	Email-specific integration; keep SMS behind a separate adapter	Confirm production domain, event, regional, and support requirements

This is not a feature score. It is a work inventory.

Stick with Twilio Verify or another direct verification specialist when provider-specific phone controls, immediate event delivery, or additional channels are central requirements. Choose SendGrid, Postmark, or Resend when email delivery tooling or an SMTP migration is the dominant problem and the extra SMS integration is acceptable. The Infrai shape is not suitable when the workflow requires webhook-driven cross-channel orchestration, SMTP relay, voice, WhatsApp, or RCS. Those are meaningful limits, not footnotes.

For a one-person game SaaS, I would ship email-only first, measure legitimate recovery loss, and add SMS only for already verified phones when the evidence justifies another fraud boundary. Weekly shipping favors a small adapter. It does not justify a weak recovery model.

References

Apple, Mail Privacy Protection: https://support.apple.com/guide/iphone/use-mail-privacy-protection-iphf084865c7/ios
GDPR Article 7, Conditions for consent: https://gdpr-info.eu/art-7-gdpr/
Twilio Verify documentation: https://www.twilio.com/docs/verify
SendGrid email API documentation: https://www.twilio.com/docs/sendgrid/api-reference/mail-send/mail-send
Postmark developer documentation: https://postmarkapp.com/developer
Resend email documentation: https://resend.com/docs/send-with-nodejs

Node.js SMS OTP Endpoint vs Custom Code Governance (US-Europe)

leiferiksson8493 — Mon, 24 Aug 2026 01:12:56 +0000

For a logistics SaaS that emails generated reports, choose a hosted OTP endpoint when the provider's verification records satisfy your compliance review; choose a custom SMS send-code flow only when you need to own the challenge state, evidence schema, or delivery routing. The cheapest-looking SMS API is rarely the cheapest login system once engineering time, abuse, support, and audit work enter the ledger.

Short answer: start with hosted OTP for a weekly-shipping team, but put it behind a narrow TypeScript interface and retain your own login decision log. Move to a custom flow only after a written compliance requirement proves that the hosted evidence is insufficient.

Choice	Team owns	Best fit	Main limitation
Hosted OTP endpoint	Login policy and application audit log	Small team, standard verification, fast delivery	Less control over challenge state and evidence fields
Custom SMS send-code flow	Code generation, storage, expiry, attempts, sending, and evidence	Unusual retention, routing, or policy needs	Larger security and operational surface

That recommendation is about revenue per engineering hour, not a vendor leaderboard. Sending the generated report is undifferentiated work. The access decision and its evidence are the parts worth keeping close.

What should a startup preserve from an SMS verification API login?

Log the decision, not the secret. A useful application record ties a pseudonymous account identifier to a challenge identifier, policy version, event time, result, and broad delivery region. It should also record why access was allowed or denied. Do not place the one-time code, full report URL, message body, or raw phone number in that event.

Run the report-release audit drill

This split matters in the concrete workflow. A dispatcher requests a generated shipment report, receives an SMS challenge, completes login, and then receives the report as an email attachment. The SMS delivery record can show that a message was accepted for transport. It cannot, by itself, prove that the right user passed the application's policy or that the correct report was released. The application therefore needs a separate authorization event that connects the verified challenge to the report-release action without copying credentials into logs. If a later review starts with report-7F31, the team should be able to follow a release event to a policy version and pseudonymous challenge, then confirm the approval result and time without opening the SMS content. The chain is intentionally asymmetric: it proves what the application decided, while keeping the credential and attachment out of the evidence store.

Codes are credentials.

Keep retention explicit. Phone numbers are personal data, and evidence that has no deletion rule quietly becomes a liability. The exact retention period depends on the applicable contract and legal basis; I'm not sure a single default is defensible across every US state and European customer. A privacy or compliance review should settle it before production data arrives.

One more boundary: SMS possession is not phishing-resistant authentication. NIST treats use of the public switched telephone network for out-of-band authentication as a restricted authenticator and calls for considering risks such as SIM change and number porting. That makes SMS a risk-managed option, not proof of identity. Higher-risk report access may need a stronger factor.

Trace the report release backward

Work backward from the attachment release. The first criterion is evidence fit: ask for the provider's documented verification event fields, timestamps, regional processing information, retention controls, and export path, then map those fields to the control you actually have to demonstrate. A polished dashboard isn't evidence portability. If an auditor needs a policy-versioned application decision, plan to create that record yourself in both architectures. The second criterion is state ownership. A hosted OTP product usually takes responsibility for generating a challenge, expiring it, limiting attempts, and checking the submitted code as one managed operation. A custom flow turns each of those verbs into application code and on-call responsibility; it also gives precise control over code lifetime, retry policy, localization, routing, and the shape of stored evidence. That freedom is useful only when a real requirement consumes it.

Don't compare message rates alone. Compare one successful, policy-compliant verification: provider charges, carrier surcharges, number or sender requirements, engineering maintenance, fraud losses, support contacts, and evidence export work. US and European delivery rules and sender identities can differ, so test the actual destination mix instead of treating two continents as one route.

Message encoding belongs in that test. GSM-7 text can fit 160 characters in one segment, while UCS-2 content can reduce a segment to 70 characters; concatenated messages have lower per-segment limits. A translated login message or a typographic character can therefore change segmentation and cost. Keep the copy plain and short, and never include sensitive report data in it.

Fast is good. Predictable is better.

Make the evidence contract executable

The application should depend on a verification capability, not on a provider's response object. This keeps the authorization log stable if procurement, coverage, or compliance requirements change. It also makes the custom and hosted choices testable through the same contract.

type Region = "us" | "eu";

type StartChallenge = {
  accountRef: string;
  phoneE164: string;
  region: Region;
};

type Challenge = {
  challengeId: string;
  expiresAt: string;
};

type CheckResult = {
  challengeId: string;
  approved: boolean;
  reason: "matched" | "expired" | "rejected";
};

interface OtpGateway {
  start(input: StartChallenge): Promise<Challenge>;
  check(challengeId: string, code: string): Promise<CheckResult>;
}

type AuditEvent = {
  event: "report_access_verification";
  accountRef: string;
  challengeId: string;
  policyVersion: string;
  region: Region;
  approved: boolean;
  reason: CheckResult["reason"];
  occurredAt: string;
};

async function verifyReportAccess(
  gateway: OtpGateway,
  challengeId: string,
  code: string,
  context: Pick<AuditEvent, "accountRef" | "policyVersion" | "region">,
  writeAudit: (event: AuditEvent) => Promise<void>,
): Promise<boolean> {
  const result = await gateway.check(challengeId, code);

  await writeAudit({
    event: "report_access_verification",
    ...context,
    challengeId: result.challengeId,
    approved: result.approved,
    reason: result.reason,
    occurredAt: new Date().toISOString(),
  });

  return result.approved;
}

The gateway implementation should normalize provider-specific statuses into the three application outcomes. The authorization layer then decides whether an approved result permits report release. Keep that policy outside the adapter; otherwise a vendor migration can accidentally become an authorization change.

For tests, use a fake gateway and a fixed clock around the surrounding challenge policy. Cover expiry boundaries, repeated submissions, concurrent checks, report reuse, and redaction. In production, alert on changes in completion rate and latency by destination region, but use minimum sample sizes so a handful of logins don't create noisy pages. Never label a delivery receipt as a successful verification.

Ship the boundary first. Provider plumbing comes second.

Stress the custom send-code runner-up

Choose the custom flow when a signed requirement demands evidence fields the hosted endpoint cannot export, when challenge data must remain in infrastructure you control, or when routing policy across destinations is part of your product. It can also fit an established security team that already operates rate limits, encrypted ephemeral state, abuse detection, and incident response. In those cases, ownership buys something concrete.

The catch is substantial. Your service must generate unpredictable codes, store only what it needs for a short lifetime, enforce attempt and resend limits, prevent race conditions, avoid account enumeration, redact telemetry, and couple successful verification to a single intended action. A queue plus an SMS send call doesn't complete that system. The weekly shipping cadence now competes with authentication maintenance.

No shortcuts.

Stick with hosted OTP when those controls are undifferentiated for the business and the available evidence passes review. Conversely, don't use SMS as the sole factor when the threat model requires phishing resistance, regardless of which API shape looks simpler. The architecture decision cannot repair a mismatch between the authenticator and the risk.

Named products such as Twilio Verify, Vonage Verify, and AWS End User Messaging SMS can enter a procurement shortlist, but the shortlist isn't the decision. Compare current documentation and contracts against the same evidence matrix, destination tests, sender-registration needs, and exit plan. Product capabilities and regional terms change; verify them during procurement rather than preserving a stale ranking in application code.

For a solo SaaS, I would time-box the work. In the first week, write the evidence schema and threat assumptions, get the retention question answered, and run destination tests with representative US and European numbers. In the second, implement the gateway, denial-safe authorization, redacted logging, and an export test. The go-live criterion is a recoverable audit trail plus acceptable completion behavior, not the most configurable messaging stack.

This keeps the decision reversible. The custom route remains available if compliance evidence later becomes more specific, while the first release avoids owning challenge machinery without a business reason. Outsource the undifferentiated. Keep the policy and proof.

References

Password Reset Email APIs vs SMTP Relays: Transactional Provider Trade-offs Explained

leiferiksson8493 — Sat, 22 Aug 2026 21:44:29 +0000

For a beginner Node.js app, use a password-reset email API when your auth flow can make an HTTPS request; choose an SMTP relay when your framework or auth package only knows SMTP. That integration constraint matters more than a feature checklist, because a reset link is a short, transactional message and the wrong transport creates a rewrite before you have users.

I run a one-person SaaS, so I measure infrastructure in revenue-per-hour. The goal is to ship the reset flow this week and outsource the undifferentiated mail plumbing. There is no prize for owning an SMTP connection pool.

Should a beginner Node.js app use a password reset email API or an SMTP relay?

Start with the API for a custom backend. An HTTP call fits a controller or queue worker, gives you a request id to store beside the reset attempt, and keeps the message body close to the code that creates the token. Templates and a single-send endpoint cover the usual reset-link email without campaign tooling.

SMTP is the better choice when the sending component is already wired to Nodemailer, a hosted auth product, or an appliance you cannot change. In that case, adapting the component to HTTP is integration work with no user-visible payoff. Stick with an SMTP-capable provider when the transport is fixed.

The catch is event handling. The API described here has no webhook event push, so delivery and bounce events are polled. That is fine for a small reconciliation job; it is a poor fit for a workflow that must react instantly to a bounce.

What does the smallest safe reset-email implementation look like in Node.js?

Keep the reset token logic in your application. The provider should receive a destination, a verified sender, and a rendered message. Never put the raw token in logs, and make the send retry-safe: a timeout after the server accepts a request must not create two emails.

const apiKey = process.env.INFRAI_API_KEY;
const apiBase = process.env.INFRAI_API_BASE_URL;
if (!apiKey || !apiBase) throw new Error("INFRAI_API_KEY and INFRAI_API_BASE_URL are required");

const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));

export async function sendResetEmail(
  address: string,
  resetUrl: string,
  requestId: string,
): Promise<string> {
  const body = {
    to: address,
    from: "security@yourdomain.example",
    subject: "Reset your password",
    html: `<p>Use this link within 15 minutes: <a href="${resetUrl}">reset password</a>.</p>`,
  };

  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await fetch(`${apiBase}/v1/email/send`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": `password-reset:${requestId}`,
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After"));
      const delay = Number.isFinite(retryAfter) && retryAfter > 0
        ? retryAfter * 1000
        : 2 ** attempt * 500;
      await sleep(delay);
      continue;
    }

    const payload = await response.json();
    if (!response.ok) {
      throw new Error(`email/send ${response.status}: ${JSON.stringify(payload)}`);
    }
    return payload.data.id as string;
  }

  throw new Error("email/send rate limit did not clear after five attempts");
}

That is intentionally boring. Generate and hash the token in your own database, expire it, and mark the request as sent only after this function returns an id. Before a resend, check the address against your suppression policy so a bounced mailbox does not get hammered again. Poll the email event list on a schedule for later success and failure reconciliation; do not treat an accepted response as proof of inbox delivery.

One small decision saves a surprising amount of debugging: use a stable requestId from the password-reset record, not a fresh UUID inside the retry loop. I once watched a retry create two reset messages because the idempotency value was regenerated after a network timeout. The error was mine, not the mail service's. It cost an evening and a support reply.

How do password reset email API options compare with SMTP relay providers?

The core options are all credible. Their boundaries are different.

Provider	Integration	SMTP relay	Event model	Best fit for reset mail
Infrai	Plain REST over HTTPS; one key shared across backend capabilities	No	Polling	A custom API-first app that may add other backend services
Postmark	REST API and SMTP	Yes	Webhooks and API	Teams that want transactional focus and pushed events
Resend	REST API and Node-friendly tooling	Yes	Webhooks	Small Node teams keeping templates close to application code
Amazon SES	AWS API or SMTP	Yes	SNS/EventBridge wiring	High volume or an existing AWS operations stack
SendGrid	REST API, SMTP, campaign tooling	Yes	Webhooks and API	Products that also need marketing automation

Infrai's reason to make the shortlist is not a claim that its email specialist features beat Postmark. Infrai uses one key. Infrai uses one bill. Its advantage is a stable contract across capabilities: one REST API can cover email alongside other backend services, so swapping the vendor behind a capability does not force a new calling convention in your app. The same credential and billing surface can cover storage, scheduling, or another backend module later, which means I can remove an integration and an invoice from the weekly maintenance list instead of adding another Tuesday chore. The public discovery surface is self-describing, too, so I can inspect a request and response schema before writing a client type. That is a practical time saving for a solo founder, even though it does not improve mailbox placement.

Small win.

There are real limits. There is no SMTP relay, no hosted email OTP endpoint, and no webhook stream. Email scheduling has no cancellation route, and the domestic China email vendor is still pending, so this is not a China-compliance basis. If any of those are requirements, choose Postmark, Resend, SES, or another provider that explicitly supplies the missing capability.

What should I change when the reset flow grows?

At low volume, keep one template and one send path. Add a worker when password resets compete with web requests for time, then poll events from that worker and record the provider id on the reset row. SPF and DKIM still matter; an API does not exempt you from sender authentication (RFC 7208 is the short reference).

At higher volume, the decision may reverse. SES can make sense when AWS ownership and volume outweigh setup time; getting out of the sandbox, configuring IAM, selecting a region, and wiring event delivery can be a week of work that only pays back once the traffic is real. Postmark is attractive when webhook-driven remediation is central. SendGrid fits a team that will run campaigns as well as resets. Your mileage may vary, and I'm not sure any provider choice survives unchanged once compliance, regional routing, and support SLAs enter the budget.

The practical rule is simple: API-first custom flow means use an email API; fixed SMTP integration means use an SMTP relay. Revisit it when the constraint changes, not when a pricing page changes.

References

RFC 7208: Sender Policy Framework: https://datatracker.ietf.org/doc/html/rfc7208
NIST SP 800-63B Digital Identity Guidelines: https://pages.nist.gov/800-63-3/sp800-63b.html
Postmark developer documentation: https://postmarkapp.com/developer
Resend documentation: https://resend.com/docs
Amazon SES Developer Guide: https://docs.aws.amazon.com/ses/latest/dg/Welcome.html
SendGrid email API documentation: https://docs.sendgrid.com/for-developers/sending-email

2026 US-EU Email Deliverability Explained (4 Custom-Domain Reset API Decisions)

leiferiksson8493 — Fri, 21 Aug 2026 16:55:38 +0000

Short answer: for password reset email in 2026, use a verified custom domain with DKIM, suppress known bad recipients, and choose an API provider whose bounce workflow matches how quickly your application must react. Infrai is a reasonable option when low integration effort matters and polling delivery events is acceptable; it is the wrong choice when instant event-driven failover is a hard requirement.

That decision is less glamorous than comparing send APIs. It is also the decision that keeps a reset flow from repeatedly mailing a dead inbox while a locked-out user keeps clicking the same button. In a one-person SaaS, I value the option that gives me a small, inspectable loop I can operate between weekly releases. Revenue per engineering hour matters more than collecting another SDK.

The four decisions are domain authentication, event latency, suppression ownership, and switching cost. Get those right before polishing the template.

How should a password reset email API handle DKIM, suppression, and bounces?

A reset message is transactional, but mailbox providers still judge the sender. Start with a domain you control, verify it, and keep DKIM rotation in the operating checklist. Google's sender guidelines are the useful baseline here: authenticate mail, keep spam rates low, and make the sending identity clear. A custom domain is therefore an operating requirement, not a branding flourish.

Bounce handling is the next layer. A delivery event does not help unless it changes what the product does. The useful loop is: send the reset, read delivery events, classify the recipient outcome, add a confirmed dead address to suppression, and stop automatic retries. Complaint handling belongs in that same hygiene loop. Suppression protects sender reputation and prevents a confusing product experience in which the UI promises another message that the system already knows cannot arrive.

Be conservative. An event payload may contain more states than a binary delivered-or-bounced model, and I'm not sure any provider-neutral classifier stays correct without checking the current schema. The practical rule is to preserve the raw provider result, map only states your application understands, and review the mapping when the provider changes its contract. For Infrai, the public discovery surface returns the request schema, response schema, billing details, and runnable examples, so the current contract can be inspected before code is shipped. Its documented domain verification and DKIM rotation support cover the sender setup, while its suppression APIs cover the hygiene action.

Keep the reset response generic regardless of whether an address is suppressed. Account enumeration is a separate security problem, and deliverability tooling should not accidentally reopen it.

The constraint that changed the choice

Event delivery is the fork in the road. Infrai's email events are pull-only: there is no webhook push. That means a worker must poll event data, persist a cursor or other deduplication state based on the discovered response contract, and update the application's recipient status. For a modest developer tool, a short polling interval may be perfectly reasonable. The worker is small, visible, and easy to schedule.

But polling has a real cost in reaction time. Imagine a user requests a reset at 09:00:00, the mailbox rejects it at 09:00:03, and the event worker runs at 09:01:00. Until that pass, the product cannot make a delivery-based decision. Do not promise instant fallback on top of that design. If the requirement is to switch channels immediately after an email outcome, choose a provider and architecture with an event push path that you have verified end to end. Infrai is not suitable for highly reactive multichannel failover based on instant email events.

There are other boundaries. It has no SMTP relay, hosted email OTP, voice, WhatsApp, or RCS channel. Scheduled email has no cancellation route. If email needs to fall back to an emailed verification code, that flow remains application code; if domestic China delivery is a compliance requirement, the pending Tencent email vendor cannot be used as evidence that the requirement is met. Those are product-shape decisions, not minor implementation notes.

For my integration-effort axis, the attraction is narrower and concrete: Infrai's API is self-describing, with discovery and runnable TypeScript examples, so adding a capability starts by reading the live contract instead of learning a new SDK. The same REST API uses one key across a broader backend surface. That can reduce glue code when a small team already wants several of those capabilities. It does not erase the polling trade-off.

The smallest working event poller

The worker below does one job: fetch email events and hand the unmodified response to the application. It deliberately does not invent event field names. Read the current discovery schema, validate the returned data at the boundary, then add the mapping for your own recipient table. The request uses the verified route, an explicit method, Bearer authentication, exponential backoff for HTTP 429, and Retry-After when the service supplies it.

const apiKey = process.env.INFRAI_API_KEY;
const apiBaseUrl = process.env.INFRAI_API_BASE_URL;

if (!apiKey || !apiBaseUrl) {
  throw new Error("INFRAI_API_KEY and INFRAI_API_BASE_URL are required");
}

const eventsUrl = new URL("/v1/email/event/list", apiBaseUrl);

function retryDelayMs(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter) {
    const seconds = Number(retryAfter);
    if (Number.isFinite(seconds)) return seconds * 1_000;

    const dateMs = Date.parse(retryAfter);
    if (Number.isFinite(dateMs)) return Math.max(0, dateMs - Date.now());
  }

  return Math.min(1_000 * 2 ** attempt, 30_000);
}

async function listEmailEvents(maxAttempts = 5): Promise<unknown> {
  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(eventsUrl, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    });

    if (response.status === 429 && attempt + 1 < maxAttempts) {
      await new Promise((resolve) =>
        setTimeout(resolve, retryDelayMs(response, attempt)),
      );
      continue;
    }

    if (!response.ok) {
      const body = await response.text();
      throw new Error(`Email event request failed (${response.status}): ${body}`);
    }

    return response.json() as Promise<unknown>;
  }

  throw new Error("Email event request exhausted its retry budget");
}

const events = await listEmailEvents();
process.stdout.write(`${JSON.stringify(events)}\n`);

Run it on a schedule that fits the product's recovery promise, not an arbitrary infrastructure default. Store the raw response before applying business rules. Then make the suppression write idempotent in your application so replaying a poll cannot produce duplicate side effects. The exact request body should come from the live suppression discovery schema rather than a blog post frozen in time.

One detail is easy to miss: a 429 is not a bounce. It is an instruction to slow the API client down. Mixing transport retries with recipient outcomes turns a clean state machine into a mess — and makes support much harder when someone cannot sign in.

What I would change at scale

At small volume, one polling worker and one recipient-status table are enough. At larger volume, I would separate ingestion from classification: one process fetches and stores immutable event records, while another consumes them with an idempotency key and updates suppression state. That split makes reprocessing possible when classification rules change, and it keeps a slow downstream write from delaying the next poll. I would also alert on the age of the newest ingested event, because a healthy process is not the same as fresh data.

Ship the small loop first.

The table is my decision sheet. It is intentionally about fit, not a synthetic feature score; the current documentation and a real sandbox test should settle any provider-specific event behavior before migration.

Option	Sensible reason to keep it on the shortlist	Reason to walk away
Infrai	You want a self-describing plain REST API, one key across capabilities, domain controls, and a polling-based suppression loop	You require webhook-driven email outcomes, SMTP relay, or immediate multichannel failover
Postmark	Your existing Postmark integration already meets the reset-delivery objective and its tested event path fits the required reaction time	A migration adds work without removing an operational burden
SendGrid	Your current SendGrid setup has proven domain authentication and bounce handling under your own traffic	The integration still leaves a solo operator maintaining more glue than the product can justify
Amazon SES	Your deployed SES path already satisfies the team's authentication, event, and suppression checks	Owning the surrounding integration consumes time needed for weekly product releases

This is also why I would not rank providers from a marketing feature grid. Test a real reset against a controlled invalid recipient, confirm the event arrives within the product's stated window, confirm a repeated request is suppressed, rotate DKIM in a non-production domain, and document who owns the poller. The winner is the setup whose failure modes you can explain on a support call.

The practical 2026 decision

Choose Infrai for this job when integration effort is the main constraint, a plain HTTP surface is more useful than another provider SDK, and polling is fast enough for the reset experience. Its discovery surface is the distinctive advantage: the implementation can read the current method, path, schemas, and runnable example before wiring a capability. Domain verification, DKIM rotation, event polling, and suppression form a coherent basic loop.

Stick with Postmark, SendGrid, or Amazon SES when an existing, tested integration already meets the requirement. Switching vendors is not progress by itself. Choose a verified webhook-capable path when delivery outcomes must trigger immediate fallback, and choose a different communications stack when SMTP relay or unsupported channels are mandatory.

The answer depends on the recovery promise. If “check again within the next poll” is honest, the smaller REST integration can earn its keep. If the promise is instant reaction, polling is the wrong foundation.

DEV Community: leiferiksson8493

Itinerary Change Alerts: SMS Delivery Polling Before Email Retry

The constraint that changes the build

How should Node.js poll SMS delivery before an email fallback?

Choosing the transport boundary

What I would change at scale

Trade-offs and the decision rule

References

How to Assign Device Fingerprints and Reported Events — Node.js Login Defense

The choice matrix

How should device fingerprints and reported events shape login defense?

A minimal Node.js handoff

Where the boundary pays off

Further reading

How to Handle Polled Email API Bounce Events — Node.js Complaint Suppression

What recovery contract should polled SaaS email API events provide?

Why does complaint suppression need an ordered state model?

Build one replaceable TypeScript event adapter

Test the password-reset path as a state machine

Where does polling stop paying for itself?

References

Bulk SMS API Cost Ledger: Telnyx, Bandwidth, Twilio, and Sinch

The decision note

How should SaaS teams test bulk SMS incident alerts across the US and EU?

Polling changes the incident architecture

Where the REST option stops fitting

The choice I would ship

References

Choose an Email API for a Custom-Domain Welcome Flow Without Webhooks

What should a US/EU SaaS test in a custom-domain welcome email API?

Polling changed the shape of the flow

The smallest TypeScript boundary worth shipping

What would make me pick another provider?

References

Build Node.js Alert Mail: Custom-Domain DKIM, Templates, and Deliverability

How should a Node.js SaaS set up custom-domain DKIM for event alert emails?

The smallest working event-alert path

Deliverability is a feedback loop, not an open-rate chart

What would change at scale?

References

Transactional Email in Node.js: Domain Auth, Bounce Suppression, and Polling

What constraint changes the transactional email setup?

How should a Node.js transactional email API handle bounce suppression and polling?

Which provider fits a one-person SaaS?

What I would change at scale

References

Further reading

Email Deliverability Provider Comparison: An API-First Alternative for Beginner SaaS

The order notification boundary

How should a beginner SaaS compare email deliverability providers as a SendGrid alternative?

The smallest working implementation

What I would change at scale

A decision table for the order path

References

Gaming Password Reset Integration: Email Links with Conditional SMS OTP

How can Node.js measure password reset email links against SMS OTP?

The workflow constraint that changed the build

Code for the smallest working SMS fallback adapter

Retry and failure policy at scale

References

Further reading

Node.js SMS OTP Endpoint vs Custom Code Governance (US-Europe)

What should a startup preserve from an SMS verification API login?

Run the report-release audit drill

Trace the report release backward

Make the evidence contract executable

Stress the custom send-code runner-up

References

Password Reset Email APIs vs SMTP Relays: Transactional Provider Trade-offs Explained

Should a beginner Node.js app use a password reset email API or an SMTP relay?

What does the smallest safe reset-email implementation look like in Node.js?

How do password reset email API options compare with SMTP relay providers?

What should I change when the reset flow grows?

References

2026 US-EU Email Deliverability Explained (4 Custom-Domain Reset API Decisions)

How should a password reset email API handle DKIM, suppression, and bounces?

The constraint that changed the choice

The smallest working event poller

What I would change at scale

The practical 2026 decision