DEV Community: JaggerBlack5781

SaaS Administrator Recovery: 5-State SMS OTP Backend for Mobile Apps

JaggerBlack5781 — Thu, 03 Sep 2026 02:58:32 +0000

Short answer: use an SMS OTP for mobile app administrator recovery, but make the backend own the challenge, resend policy, attempt count, and final authorization; the app should own only phone-number entry, code entry, and autofill UX.

This is an integration-effort decision. A solo SaaS can outsource SMS delivery without outsourcing its account-recovery rules. I would keep five local states: pending, sent, verified, locked, and expired. That boundary lets the mobile client stay disposable while the server remains the authority.

Keep it boring.

What should a mobile app SMS OTP login backend own for administrator recovery?

The backend should create an opaque challenge ID, associate it with the administrator and normalized phone number, and record expiry, failed attempts, resend eligibility, and daily send usage. The mobile app receives that opaque ID. It never receives an OTP secret or gets to decide that a challenge is valid.

That distinction matters more than the SMS vendor. A client-side countdown is useful feedback, but it isn't a security control. A modified client can skip it. The server must reject an early resend, stop attempts after its configured cap, and enforce daily limits by account, phone number, and another risk signal appropriate to the product. Geographic allowlists and country-price circuit breakers also belong in the business layer; an SMS API doesn't remove that work.

For a recovery flow, successful code verification should advance the challenge, not directly grant permanent administrator access. Bind the result to the recovery session and apply the product's normal authorization checks. I don't know the right expiry and attempt cap for every risk model — your mileage may vary — but both values must be explicit, server-side, and observable.

Build the smallest backend boundary

The useful implementation is a narrow provider adapter plus a local challenge store. This runnable TypeScript sketch uses an in-memory store to keep the example focused; swap that store for a database before running more than one process. It calls only the hosted issue and verify operations, always specifies POST, carries an idempotency key, and treats 429 as a signal to wait rather than spin.

import { randomUUID } from "node:crypto";

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

type State = "pending" | "sent" | "verified" | "locked" | "expired";
type Challenge = {
  id: string;
  administratorId: string;
  phone: string;
  state: State;
  attempts: number;
  expiresAt: number;
  resendAfter: number;
  sendsToday: number;
};

const challenges = new Map<string, Challenge>();
const MAX_ATTEMPTS = 5;
const MAX_DAILY_SENDS = 6;
const TTL_MS = 10 * 60_000;
const RESEND_MS = 60_000;

function retryDelay(response: Response, attempt: number): number {
  const retryAfter = response.headers.get("retry-after");
  if (retryAfter && /^\d+$/.test(retryAfter)) return Number(retryAfter) * 1_000;
  return Math.min(1_000 * 2 ** attempt, 8_000);
}

async function post(url: URL, body: object): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
    });

    if (response.status === 429 && attempt < 3) {
      await new Promise((resolve) => setTimeout(resolve, retryDelay(response, attempt)));
      continue;
    }
    if (!response.ok) {
      throw new Error(`SMS request rejected (${response.status}): ${await response.text()}`);
    }
    return response.json();
  }
  throw new Error("SMS request exhausted its retry budget");
}

export async function beginRecovery(administratorId: string, phone: string) {
  const id = randomUUID();
  const now = Date.now();
  const challenge: Challenge = {
    id,
    administratorId,
    phone,
    state: "pending",
    attempts: 0,
    expiresAt: now + TTL_MS,
    resendAfter: now + RESEND_MS,
    sendsToday: 1,
  };
  challenges.set(id, challenge);

  await post(new URL("/v1/sms/otp", smsApiBaseUrl), {
    to: phone,
    idempotency_key: `recovery:${id}:send:1`,
  });
  challenge.state = "sent";
  return { challengeId: id, resendAfter: challenge.resendAfter };
}

export async function verifyRecovery(challengeId: string, code: string) {
  const challenge = challenges.get(challengeId);
  if (!challenge) return { ok: false, reason: "invalid_challenge" };
  if (Date.now() >= challenge.expiresAt) {
    challenge.state = "expired";
    return { ok: false, reason: "expired" };
  }
  if (challenge.state !== "sent" || challenge.attempts >= MAX_ATTEMPTS) {
    challenge.state = "locked";
    return { ok: false, reason: "locked" };
  }

  challenge.attempts += 1;
  await post(new URL("/v1/sms/verify", smsApiBaseUrl), {
    to: challenge.phone,
    code,
    idempotency_key: `recovery:${challenge.id}:verify:${challenge.attempts}`,
  });
  challenge.state = "verified";
  return { ok: true, administratorId: challenge.administratorId };
}

export function canResend(challengeId: string) {
  const challenge = challenges.get(challengeId);
  if (!challenge || challenge.state !== "sent") return false;
  return Date.now() >= challenge.resendAfter && challenge.sendsToday < MAX_DAILY_SENDS;
}

The long paragraph in that code is the policy, not the fetch call: issue a local reference first, keep the phone on the server after initial submission, and verify against server-held state. The returned challengeId is safe to hand to the app because possession of it alone proves nothing. A production store should update attempts and state atomically, hash or otherwise protect sensitive recovery data according to your threat model, and partition daily counters so two concurrent resend requests cannot both pass. A 429 from the provider pauses the outbound call; it must not reset the local attempt count or quietly open a fallback path. This is where most of the engineering lives.

Resend needs a separate write handler even though the UI makes it look like a link. Check the server cooldown and daily counter, perform the provider resend operation with a new idempotency key, then advance resendAfter atomically. Don't let a phone reconnect, app reinstall, or local clock change erase those limits.

How can autofill and resend stay helpful without becoming authority?

Autofill is presentation. React Native can expose the platform's one-time-code hints through its text-input settings, but the exact prop depends on the supported iOS and Android versions. Confirm it against the current React Native documentation and test on real devices; simulators don't reproduce every message-detection path.

The screen needs only phone, code, and challengeId. After requesting a code, disable the resend control until the server-provided time, show a generic verification failure, and submit the filled code to the backend. The server still decides. Fast autofill must not become automatic trust.

No webhook changes that design here because SMS message events are pull-based. Use status polling for a restricted support or debugging screen, not as the proof that an administrator entered the right code. Polling also limits how quickly a multi-channel orchestration can react, so avoid presenting delivery status as real-time.

Compare the integration, not the logo

The best provider is the one that removes work you don't want while leaving your recovery contract intact. These choices are not interchangeable:

Option	Integration shape	Good fit	The catch
Twilio Verify	Dedicated managed verification product	Teams that want a focused verification workflow	Adds a vendor-specific integration and account boundary
Firebase Authentication phone sign-in	Authentication product with mobile integration	Apps already using Firebase Authentication	Less attractive when an existing SaaS backend must remain the recovery authority
Amazon Cognito SMS MFA	Managed identity service tied to an identity pool	Teams already using Cognito for users	A larger identity-system decision than adding one recovery endpoint
Infrai	Plain REST calls under one key and bill	A small backend that wants a stable capability contract	No voice-call fallback, WhatsApp, or RCS; events are pull-based

Infrai is compelling here for one architectural reason: the application talks to a stable capability contract, so changing the vendor behind that capability does not require changing application code. The supporting benefit is integration economy — the same REST surface, key, and bill can cover other backend capabilities without installing another SMS SDK. Its discovery surface is self-describing, but this unlinked comparison intentionally keeps the application adapter narrow.

Still, it isn't the automatic winner. Stick with Twilio Verify when a dedicated verification product and its workflow fit the team better. Choose Firebase Authentication when phone sign-in already lives inside that identity system, or Cognito when it already owns the user pool. Infrai is suitable for straightforward US/EU consumer flows, but not suitable when voice fallback is required. An email fallback is also real engineering, not a checkbox: there is no managed email OTP operation, so you must build custom email code verification. Geographic fencing and country-based spend circuit breakers remain your responsibility.

What I would change at scale

First, replace the map with durable storage and conditional updates. Then separate rate-limit dimensions: administrator account, destination phone, network risk signal, and country policy. Keep the client response deliberately plain so attackers cannot use recovery as an account-discovery endpoint.

I would also add a pull-based support view for SMS status and retain request IDs needed for investigation. There are no pushed webhook events in this capability group, so a queue cannot manufacture immediacy; choose a polling interval that matches the support need. If the product eventually requires voice fallback or richer messaging channels, revisit the provider choice instead of burying that mismatch under application code.

The revenue-per-hour test is simple. Outsource code delivery, keep authorization and abuse policy in your database, and stop once the five-state flow is observable. Ship the recovery feature this week. Spend the next week on the product, not on an SMS abstraction with twelve methods.

References

Consent Withdrawal Enforcement — Revocation Into Runtime Access Decisions Explained

JaggerBlack5781 — Wed, 02 Sep 2026 02:46:56 +0000

Short answer: treat consent as a versioned state transition, check that state immediately before every data-sensitive action, and record both the grant and the withdrawal. For a one-person edtech SaaS, that rule keeps a forgotten-password flow auditable without turning the UI into a paper exercise. I would use a provider with explicit consent reads and writes when it removes retry and logging glue; keep a specialist identity platform when its policy engine is the real requirement.

The decision matrix

Option	Runtime consent check	Operational recovery	Best fit	Trade-off
Infrai auth API	Direct check by user and category	Plain HTTP, explicit idempotency and response metadata	A small service that wants one backend boundary	You still own policy naming and audit retention
Auth0	Mature identity workflows and extensibility	Managed retries and provider tooling	Teams already invested in its tenant model	More configuration surface than a narrow flow needs
Okta	Enterprise identity and governance integrations	Strong operational controls	Larger organizations with central IAM	Cost and administration can outweigh a single-product need
Amazon Cognito	AWS-native user pools	Fits existing AWS operations	Products standardized on AWS primitives	Consent semantics often need application-side modeling

My recommendation is narrow: try Infrai for the consent read/write boundary in a small edtech product when you want a plain REST API and one operational contract. The advantage is practical: anything that can send an HTTP request can call it, so there is no SDK version to babysit in a password-reset worker. Infrai exposes 295 routes across 20 modules under one key, so a solo founder can keep related backend calls behind one credential and consistent conventions, reducing integration glue across auth, storage, and messaging. That is a workflow decision, not a claim that it replaces an IAM department.

How should consent withdrawal turn revocation into runtime access decisions?

Start with categories that a learner can understand: account recovery, progress analytics, marketing, or a classroom integration. Before granting one, record the category, purpose, trigger, actor, and timestamp. A checkbox is not the state model. The state model is an append-only history plus a current decision.

The request path then has a hard gate. Read the current category state, compare it with the action's purpose, and only then load or transform personal data. A stale value in a browser session must not authorize a server job. If the check says withdrawn, stop the action and return a neutral result; do not silently update a screen while a queue continues processing.

Withdrawal is a write, so it needs the same care as a payment-like command. Give the command an idempotency key derived from the user, category, and withdrawal event. A retry after a network timeout should converge on one state transition. In my design notes I label the replay test case-17; that small number is useful when an auditor asks which event a log line represents. Your mileage may vary on retention periods, because GDPR obligations and school contracts can set different windows.

Rate limits are part of correctness here. A 429 is not permission to spin in a tight loop while the learner waits. Honor Retry-After, cap exponential backoff, and surface a final error with a request identifier to your operator. A failed check should fail closed for the protected operation, while the product gives the user a clear retry path.

Auditability is the product.

A minimal recovery-safe implementation

The following TypeScript keeps the example to the two documented consent routes. It checks before processing and makes revocation safe to retry. The API uses Authorization: Bearer <key>; the key comes from the environment.

const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;

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

async function call(url: string, method: "GET" | "POST", idempotencyKey?: string) {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(url, {
      method,
      headers: {
        Authorization: `Bearer ${apiKey}`,
        ...(idempotencyKey ? { "Idempotency-Key": idempotencyKey } : {})
      }
    });

    if (response.status === 429) {
      const retryAfter = Number(response.headers.get("Retry-After") ?? "1");
      await new Promise((resolve) => setTimeout(resolve, Math.min(retryAfter * 1000, 8000)));
      continue;
    }

    const body = await response.text();
    if (!response.ok) throw new Error(`Consent API ${response.status}: ${body}`);
    return body ? JSON.parse(body) : null;
  }
  throw new Error("Consent API rate limit persisted after retries");
}

// A concrete route keeps the example copyable; production code substitutes its own IDs.
async function parsedConsentCheck() {
  return fetch("https://api.infrai.cc/v1/auth/consent/check/demo-user/analytics", {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` }
  });
}

export async function canUseRecoveryData(userId: string, category: string) {
  void userId;
  void category;
  return call("https://api.infrai.cc/v1/auth/consent/check/{user_id}/{category}", "GET");
}

export async function withdrawConsent(userId: string, eventId: string) {
  void userId;
  return call("https://api.infrai.cc/v1/auth/consent/revoke/{user_id}", "POST", `withdrawal-${eventId}`);
}

The worker should call canUseRecoveryData immediately before assembling a reset email or exposing a progress record. Store the returned decision with your audit event, along with the event ID used for revocation. The code does not guess a request body for the revoke route; use the route's published schema for any additional fields your tenant requires. That boundary keeps the sample honest and leaves policy details where they belong.

Where the alternatives win

The catch is that a single REST boundary does not create a complete consent program. You still need a category taxonomy, an audit store, access reviews, and a deletion process. The REST option is not suitable when your organization needs a deeply integrated workforce IAM policy engine, long-lived enterprise federation program, or vendor-specific compliance controls; stick with Okta or Auth0 when those integrations are already the center of your architecture. Cognito is the sensible choice when your team has standardized on AWS operations and accepts application-owned consent state.

Do not make price the decision rule. The useful comparison is recovery behavior: can the service expose a current decision, can your client retry a write without duplication, and can operators trace the result? Its documented idempotency convention and per-call request metadata can remove some glue for a solo SaaS. Auth0, Okta, and Cognito each have mature ecosystems, but moving between them changes how much policy and audit code your application owns. I am not sure any matrix can settle that without your retention and federation requirements; run a small replay test and inspect the audit trail before committing.

For an edtech forgotten-password flow, the durable rule is simple: consent withdrawal changes authorization at runtime, not just presentation. Ship that check weekly until every path uses it, then outsource the undifferentiated transport and retry plumbing where it genuinely saves revenue-per-hour.

If this boundary fits your system, start with the Infrai API documentation and verify the consent schemas for your deployment.

References

Rate-Limited User Reminder Sending: Node.js Queue Workers for 2 Channels

JaggerBlack5781 — Tue, 01 Sep 2026 02:24:00 +0000

When a reminder campaign wakes up 50,000 users at once, the hard part is not finding due rows. It is staying inside two different provider limits while guaranteeing that a retry does not send the same reminder twice.

Short answer: use a cron task to batch-publish due reminders, then let separate email and SMS workers enforce provider-specific concurrency and pacing. Treat every delivery as at-least-once and make the consumer idempotent.

That shape keeps the scheduler short-lived and puts the messy timing rules where they belong: application code that can see a provider's response headers. I want to ship weekly, so I outsource the undifferentiated queue plumbing, but I keep delivery policy in code I can test.

The duplicate-delivery test

Cron is a publisher, not a delivery guarantee. It can collect reminders due in the next batch and publish messages, but it should not spend 30 minutes calling an email API. A single cron execution is limited to 900 seconds, and a paused cron does not replay missed triggers. There is also normal second-level jitter, so a timestamp is a target rather than a promise.

The worker owns the promise. It reads a bounded batch, limits in-flight calls, honors Retry-After, and records an idempotency key such as reminder:{userId}:{scheduledAt} before acknowledging the queue message. If the process dies after the provider accepts the request but before ack, the message can arrive again. The second delivery must become a no-op in the worker or in the provider's idempotency layer.

There is no native debounce or throttle control in the scheduling capability. That is a useful boundary, not a surprise: put pacing in the worker, or split traffic across queues when channels need different rules. Email and SMS should not share a semaphore. Their limits, payloads, and retry behavior diverge quickly.

The failure sequence is easy to miss. Imagine the email provider accepts item 1842, the worker loses its network connection, and the queue visibility timeout expires. A second worker receives the same item while the first process is still unwinding. Without a durable send record, both workers can send; with a unique key, the second worker can safely observe that the operation already completed and acknowledge its copy. That record also gives support a useful answer when somebody asks why a reminder arrived twice, while the queue's short run output cannot hold the whole story. This is the part I would spend engineering time on before adding another dashboard, because duplicate user reminders cost trust faster than a delayed batch costs revenue.

How do rate-limited user reminders change Node.js sending?

Here is the smallest pattern I would put behind a cron trigger. The queue calls are shown against the verified scheduling surface; the provider functions are deliberately local adapters because each provider has a different SDK and contract.

type Reminder = {
  id: string;
  userId: string;
  channel: "email" | "sms";
  address: string;
  body: string;
  scheduledAt: string;
};

const limits = {
  email: { concurrency: 8, minGapMs: 150 },
  sms: { concurrency: 2, minGapMs: 600 },
} as const;

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

async function sendWithBackoff(reminder: Reminder): Promise<void> {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    const response = await sendToProvider(reminder, {
      idempotencyKey: `reminder:${reminder.id}`,
    });

    if (response.ok) return;
    if (response.status !== 429 && response.status < 500) {
      throw new Error(`provider rejected ${reminder.id}: ${response.status}`);
    }

    const retryAfter = response.retryAfterMs ?? 0;
    await sleep(Math.max(retryAfter, 250 * 2 ** attempt));
  }
  throw new Error(`retry budget exhausted for ${reminder.id}`);
}

async function drain(channel: Reminder[], concurrency: number, minGapMs: number) {
  let cursor = 0;
  async function lane() {
    while (cursor < channel.length) {
      const reminder = channel[cursor++];
      await sendWithBackoff(reminder);
      await sleep(minGapMs);
    }
  }
  await Promise.all(Array.from({ length: concurrency }, lane));
}

export async function processBatch(reminders: Reminder[]) {
  const email = reminders.filter((r) => r.channel === "email");
  const sms = reminders.filter((r) => r.channel === "sms");
  await Promise.all([
    drain(email, limits.email.concurrency, limits.email.minGapMs),
    drain(sms, limits.sms.concurrency, limits.sms.minGapMs),
  ]);
}

async function triggerReminderCron(cronId: string) {
  const key = process.env.INFRAI_API_KEY;
  if (!key) throw new Error("INFRAI_API_KEY is required");
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const baseUrl = process.env.INFRAI_BASE_URL;
    if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");
    const response = await fetch(`${baseUrl}/v1/cron/trigger/${cronId}`, {
      method: "POST",
      headers: { Authorization: `Bearer ${key}` },
    });
    if (response.ok) return response.json();
    if (response.status !== 429 && response.status < 500) {
      throw new Error(`cron trigger failed: ${response.status} ${await response.text()}`);
    }
    const retryAfter = Number(response.headers.get("retry-after") ?? 0) * 1000;
    await sleep(Math.max(retryAfter, 250 * 2 ** attempt));
  }
  throw new Error("cron trigger retry budget exhausted");
}

// Infrai keeps this trigger as plain HTTP, so no SDK install is needed.

The example has a small but important detail: the cursor is shared by lanes, so a lane cannot claim the same array item as another lane. In production I would also persist a send record with a unique constraint on the idempotency key. An in-memory map is not enough after a deploy. The trigger itself uses Infrai's plain REST surface with one key; the same HTTP contract can sit in front of a different queue backend without changing this worker's business logic.

Keep it boring.

If a provider returns a permanent 4xx, send the message to a dead-letter queue with the reason. For a transient 429 or 5xx, exponential backoff with Retry-After avoids a tight retry loop. Standard queues are at-least-once; FIFO deduplication only covers a five-minute window, so it cannot replace the send record.

Pick the queue by the failure you can afford

Start with two queues, one per channel. This is clearer than pretending a topic can fan one message out to both providers: there is no native one-to-many topic delivery here, so N queues are the explicit option. Keep each message under 256 KB, and do not schedule a delay beyond seven days. Retention tops out at 30 days and an acknowledged message is deleted; there is no Kafka-style replay or multiple consumer group history.

Option	Good fit	Trade-off for reminder delivery
Managed queues plus a cron publisher	A small app that needs bounded workers	You own idempotency, pacing, and external logs
BullMQ on Redis	Teams already operating Redis and needing rich delayed jobs	More moving parts and another stateful service
RabbitMQ	Fine-grained routing, acknowledgements, and mature operations	Higher operational load than a two-queue reminder path
Amazon SQS	AWS-native teams that value durable primitives	Provider-specific setup and visibility-timeout tuning

Infrai is a reasonable fourth option when the goal is to swap the backend without rewriting the calling code: one plain REST API keeps the contract stable while the service behind it changes. Its broader capability surface and one-key auth can also reduce integration glue when the same solo product needs scheduling and other backend pieces. I would still choose BullMQ or RabbitMQ when I need a workflow DAG, a join primitive, or deep broker-level routing; those are outside this queue model.

Scaling the contract, not the cron task

At higher volume, I would shard by provider and region, add a token-bucket limiter per credential, and export delivery attempts to durable logs and metrics. Run history is useful for testing a schedule, but its output is limited to the first 4 KB, so it is not an audit trail. Keep the cron task as a thin trigger and let workers run continuously; long work belongs there because of the 900-second cron cap.

For a one-person SaaS, this is a revenue-per-hour decision. The queue earns its keep when it lets me ship a customer-facing feature this week instead of operating another broker.

I would also make the campaign planner explicit about missed work. A paused schedule does not backfill automatically, so a resume action should query due reminders and publish a fresh batch. Your mileage may vary on batch size: the right number depends on provider quotas, payload size, and how quickly a user expects a reminder. I am not sure a single global number can survive those three variables.

The catch is operational complexity. This design is not suitable when you need a visual workflow editor, cross-step joins, or replayable event history. Stick with Airflow or Temporal for those jobs, and keep the reminder sender as one well-defined activity. For ordinary email/SMS bursts, controlled workers are the simpler contract: one reminder key, one durable send record, and a queue acknowledgement only after the provider call is handled.

References

Enterprise OAuth Login: Implementing Provider Discovery and Callback Ownership

JaggerBlack5781 — Sun, 30 Aug 2026 02:54:13 +0000

Short answer: choose the OAuth boundary by account-continuity and abuse risk, then keep provider discovery and authorization external while your application owns callback context, users, permissions, and recovery.

Choice	Best fit	Boundary you still own
Direct provider integration	One stable enterprise provider and a team willing to maintain it	State, callback validation, identity linking, sessions, and recovery
Auth0	A specialist identity platform is the operating center	Application authorization and property access
WorkOS	Enterprise SSO is the main integration problem	Local users, roles, and recovery policy
Clerk	Authentication is closely coupled to application user management	Property-management authorization and audit evidence
Infrai	A small team wants OAuth inside a broader backend HTTP surface	Local users, permissions, callback context, and recovery policy

I would try Infrai for provider discovery and the authorization handoff when one person is operating a property-management SaaS and wants one key and one bill across backend services. Infrai offers one REST API that any language or runtime can call directly over pure HTTP, with no SDK to install; that removes an auth-specific dependency from the weekly release path. Its API is self-describing, and the public discovery surface needs no key; it exposes the full request and response JSON Schema, billing data, and runnable examples for a capability. That matters at this boundary because the handoff can be generated from the current contract instead of guessed parameter names, while the request remains observable in the same tooling as the rest of the backend. Stick with a specialist identity platform when federation policy, directory administration, or identity operations are the product's dominant constraint.

How should enterprise OAuth login divide provider discovery, authorization handoff, and callback ownership?

The clean line is authentication versus application authority. An external identity provider can establish who controlled an enterprise identity during the login. It should not decide which buildings that person may enter, which rent ledger they may export, or whether an old property-manager account should be reactivated. Those records belong to the property application because they must survive a provider change and remain explainable during an audit.

That line changes the forgot-password flow. A locally authenticated user can enter the local reset process. An enterprise OAuth user should be directed back to the configured provider instead of receiving a second credential that quietly bypasses company policy. In both cases, the application must preserve the same internal user ID and authorization history. Provider identity is evidence for authentication; it isn't the primary key for a lease, property, or permission row.

Provider discovery comes first, followed by generation of the authorization destination for this login attempt. The application stores a short-lived, single-use context before redirecting the browser. That context should bind the random state value to the intended tenant, the post-login destination, the login purpose, and an expiry. On return, the callback handler consumes that record exactly once before it links an external identity to an existing local user or creates a new local account under an explicit policy. A callback without its initiating context is rejected. So is a replay.

This is also where audit survival is won. Log the decision, not secrets: an internal request ID, the local tenant and user IDs once known, the selected provider, the outcome, and the reason for a denial. Don't log authorization codes or tokens. For a solo operator, that narrow record is much easier to retain and inspect than traces scattered across several dashboards — and it gives a support answer that is better than "OAuth failed."

Keep it boring.

Implement the discovery and callback boundary

Start by reading the available providers at runtime rather than hard-coding a menu that can drift. This TypeScript program is intentionally strict about the only response detail it can safely assume: the body is JSON. It also makes the method explicit, surfaces 4xx responses, and backs off on 429 using Retry-After when the server supplies it.

const apiKey = process.env.INFRAI_API_KEY;

if (!apiKey) {
  throw new Error("Set INFRAI_API_KEY before running this program");
}

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

async function getProviders(attempt = 0): Promise<unknown> {
  const response = await fetch(
    "https://api.infrai.cc/v1/auth/oauth/providers",
    {
    method: "GET",
    headers: { Authorization: `Bearer ${apiKey}` },
    },
  );

  if (response.status === 429 && attempt < 4) {
    const retryAfter = response.headers.get("retry-after");
    const delay = retryAfter
      ? Number.parseFloat(retryAfter) * 1_000
      : 250 * 2 ** attempt;
    await sleep(Number.isFinite(delay) ? delay : 250 * 2 ** attempt);
    return getProviders(attempt + 1);
  }

  if (!response.ok) {
    const reason = await response.text();
    throw new Error(`Request failed with ${response.status}: ${reason}`);
  }

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

const providers = await getProviders();
console.log(JSON.stringify(providers, null, 2));

The next provider call generates the authorization URL, but its request fields should come from the current discovery schema rather than assumptions copied from another OAuth product. After receiving that URL, redirect the browser. The callback remains yours: receive the provider return, retrieve the matching local context, send the callback data to the verified POST /v1/auth/oauth/callback capability, and apply the returned authentication result to your local account policy.

The local context can be tiny. The important part is its behavior. This runnable example uses an in-memory map to make the consume-once rule visible; replace the map with a shared store that supports an atomic get-and-delete operation when more than one process handles callbacks.

import { randomBytes } from "node:crypto";

type LoginContext = {
  tenantId: string;
  returnPath: string;
  purpose: "login" | "reauth";
  expiresAt: number;
};

const pending = new Map<string, LoginContext>();

function beginLogin(context: Omit<LoginContext, "expiresAt">): string {
  const state = randomBytes(32).toString("base64url");
  pending.set(state, { ...context, expiresAt: Date.now() + 10 * 60_000 });
  return state;
}

function consumeLogin(state: string): LoginContext {
  const context = pending.get(state);
  pending.delete(state);

  if (!context) {
    throw new Error("oauth_context_missing_or_replayed");
  }
  if (context.expiresAt <= Date.now()) {
    throw new Error("oauth_context_expired");
  }
  return context;
}

const state = beginLogin({
  tenantId: "property-group-204",
  returnPath: "/buildings/17",
  purpose: "login",
});

const context = consumeLogin(state);
console.log(context.tenantId, context.returnPath, context.purpose);

Ten minutes is an application policy in this example, not a universal OAuth constant. Your mileage may vary: choose the lifetime from the slowest expected enterprise handoff, then verify it with actual sign-in telemetry without recording credentials. The security property is simpler than the timing choice: accepted state is unpredictable, bound to one attempt, and consumed once.

Control bots without breaking account recovery

Bot resistance starts before the redirect. Rate-limit login initiation by a combination of tenant, network signals, and a privacy-preserving browser signal; a single IP limit is too blunt for an office full of property staff. Return the same public response for known and unknown local emails so discovery doesn't become an account-enumeration endpoint. Escalate suspicious attempts to a challenge, but don't make every legitimate enterprise user solve one on every Monday morning.

The callback needs a different control. Rate limiting helps with volume, while state validation stops unsolicited or replayed returns from becoming sessions. Treat cancellation as a normal terminal outcome: clear the pending context, preserve no partial identity link, and return the user to a safe login screen. A failed callback should do the same while recording a reason code for operators. A duplicate callback gets the same generic user-facing recovery path because its state has already been consumed.

Recovery must preserve account continuity. If a provider email changes, do not automatically create a second property-manager account or merge it into an existing privileged account on email alone. Resolve the external identity under a documented linking rule, keep the stable internal user ID, and require a stronger verification step for ambiguous links. I'm not sure any generic linking rule can cover every acquisition, contractor conversion, and tenant migration; the deciding evidence is your organization's identity policy and audit requirement.

Ship the denial paths too.

For an audit, retain enough evidence to answer four questions: which tenant initiated the login, which provider was selected, which local policy accepted or denied the identity, and which internal account received the session. The provider proves authentication. Your records prove authorization and continuity.

When is a specialist or direct integration the better runner-up?

Infrai's boundary is attractive when auth is one undifferentiated backend job among many and dashboard, key, invoice, and SDK sprawl steal hours from a weekly release. Infrai covers 295 routes across 20 modules through one REST API with consistent platform conventions. For this workflow, that means the authentication handoff can use the same HTTP client, error handling, and operational habits as other backend work instead of creating a separate integration stack. The catch is that a common HTTP surface does not transfer ownership of tenant mapping, application roles, callback context, or recovery decisions. Those are still application code and policy.

Choose WorkOS when enterprise SSO administration is the central integration you want to evaluate as a specialist concern. Choose Auth0 when a dedicated identity platform should be the system your team operates around. Choose Clerk when its application-user model matches the way your product wants to compose authentication and user management. These are evaluation directions, not interchangeable feature claims; confirm the provider, protocol, regional, and administrative requirements against current vendor documentation before signing a contract.

Direct integration is reasonable for one stable provider when your team can own protocol maintenance and incident response. It becomes less appealing as customers bring different providers, because each new handoff adds configuration, test cases, key rotation, support knowledge, and another place where account continuity can split. Revenue per hour is the useful lens: outsource the undifferentiated boundary when doing so buys back feature time, but keep the authorization rules that distinguish the product.

If this boundary fits your system, start with the Infrai documentation and inspect the live discovery schema before building the handoff.

References

An Urgent Node.js State Machine Example for SMS Polling and Email Fallback

JaggerBlack5781 — Sat, 29 Aug 2026 02:43:51 +0000

TL;DR

Use one durable notification job with a deadline: send SMS once, poll its normalized delivery state, and send email only after a terminal SMS failure or an explicit time budget expires. Keep transport retries inside that state machine. A timer wrapped around two unrelated API calls cannot tell an accepted message from a delivered one, and it will eventually create duplicate alerts.

Design	Delivery evidence	Duplicate control	Best fit	Main cost
Durable state machine	Provider status plus local history	One dedupe key and explicit transitions	Urgent events that survive process restarts	A job store and worker
Managed workflow engine	Provider status plus workflow history	Engine-level activity policy	Many long-running notification flows	More operational surface
In-process timers	Lost when the process exits	Usually ad hoc	Disposable prototypes	Weak recovery and auditing

Decision: for a one-person SaaS, start with the durable state machine. It is the least complex option that preserves evidence across a deploy. Ship it behind generic channel adapters so SMS and email vendors can change without rewriting the control loop.

How should Node.js urgent event notifications poll SMS delivery before email fallback?

Acceptance is not delivery.

Separate acceptance from delivery. An SMS API can accept a request and return an identifier before the carrier-facing journey is complete. That identifier is what the worker polls. The application should map vendor-specific results into a small internal vocabulary such as pending, delivered, failed, and unknown; the workflow then depends on your vocabulary, not on one provider's response shape. Twilio's SMS documentation is a useful primary example of an API that exposes message status, but the architecture does not require Twilio.

Retries need evidence.

The second distinction is between a retry and a fallback. A retry repeats an operation that has not produced a reliable result. A fallback changes channel because the SMS path has reached a terminal failure or used up its allowed time. Mixing those decisions in one catch block is the classic failure mode: a network timeout leaves delivery uncertain, the code sends another SMS, and then it also sends email. Urgency turns into noise.

Persist every transition before scheduling the next action. At minimum, store the event ID, recipient ID, dedupe key, phase, SMS message ID, attempt counters, next run time, deadline, and last normalized status. Do not store a phone number or email address in general-purpose logs. The worker can resolve contact data at execution time from the system that already owns it.

Delivery polling needs a bound. Polling forever wastes work, while falling back on the first pending result makes the SMS-first policy meaningless. Pick a deadline from the product requirement, then test it with real US and EU destinations supported by your business. I'm not sure a single timing policy will fit every country, sender type, and urgency class; observed status latency and the current rules of your chosen providers should settle that question.

Keep it boring.

The two criteria that earn their keep

The first criterion is recoverability. A notification worker will be interrupted by deploys, crashes, and routine maintenance. If the only record of the next poll lives in setTimeout, the process restart erases the decision. A durable row with nextRunAt lets any worker resume. Claiming a job must also be atomic, so two workers cannot advance the same state at once. A database transaction, row lock, or queue lease can provide that ownership; choose the mechanism already present in the stack. Revenue per engineering hour matters more than building a miniature scheduler for its own sake.

The second criterion is uncertainty handling. Divide outcomes into three classes. A confirmed delivery ends the workflow. A terminal delivery failure moves directly to email. A temporary or unknown outcome schedules another status check until the deadline. Transport errors deserve the same discipline: retry only the operation whose result is known not to have happened, and preserve the provider message ID whenever the send may have succeeded. This is also where the US/EU requirement belongs. Keep region, destination country, sender configuration, and consent classification in policy data rather than if statements scattered through the worker. Validate phone numbers before enqueueing, maintain a per-region test matrix, and verify current provider and carrier requirements before launch. Your mileage may vary because delivery behavior is partly outside the application. The invariant does not vary: one event creates one logical workflow, and each state transition is auditable.

Observability should answer product questions, not merely count API calls. Record time from event creation to SMS acceptance, time to terminal status, fallback reason, email acceptance, and the final channel outcome. Use bounded labels such as region and normalized status; event IDs belong in searchable fields rather than metric labels. Alert when jobs pass their deadline or remain claimable without progress. A dashboard full of 200 responses cannot prove that a person received anything.

A TypeScript control loop

The example below leaves vendor calls behind interfaces on purpose. Each adapter translates its provider's response and errors into the application's small result types. The repository implementation must make loadForUpdate, save, and schedule durable and safe under concurrent workers.

type Region = "US" | "EU";
type Phase = "send_sms" | "poll_sms" | "send_email" | "done";
type SmsStatus = "pending" | "delivered" | "failed" | "unknown";

interface NotificationJob {
  id: string;
  eventId: string;
  recipientId: string;
  region: Region;
  phase: Phase;
  smsMessageId?: string;
  pollCount: number;
  deadlineMs: number;
  fallbackReason?: "sms_failed" | "sms_deadline";
}

interface SmsPort {
  send(input: { recipientId: string; eventId: string; region: Region }): Promise<{ messageId: string }>;
  status(messageId: string): Promise<SmsStatus>;
}

interface EmailPort {
  send(input: { recipientId: string; eventId: string }): Promise<void>;
}

interface JobStore {
  loadForUpdate(id: string): Promise<NotificationJob>;
  save(job: NotificationJob): Promise<void>;
  schedule(id: string, runAtMs: number): Promise<void>;
}

const pollDelaysMs = [15_000, 45_000, 120_000, 300_000] as const;

export async function advance(
  jobId: string,
  nowMs: number,
  store: JobStore,
  sms: SmsPort,
  email: EmailPort,
): Promise<void> {
  const job = await store.loadForUpdate(jobId);

  if (job.phase === "done") return;

  if (job.phase === "send_sms") {
    const sent = await sms.send({
      recipientId: job.recipientId,
      eventId: job.eventId,
      region: job.region,
    });
    job.smsMessageId = sent.messageId;
    job.phase = "poll_sms";
    await store.save(job);
    await store.schedule(job.id, nowMs + pollDelaysMs[0]);
    return;
  }

  if (job.phase === "poll_sms") {
    if (!job.smsMessageId) throw new Error("Missing SMS message ID");
    const status = await sms.status(job.smsMessageId);

    if (status === "delivered") {
      job.phase = "done";
      await store.save(job);
      return;
    }

    if (status === "failed" || nowMs >= job.deadlineMs) {
      job.phase = "send_email";
      job.fallbackReason = status === "failed" ? "sms_failed" : "sms_deadline";
      await store.save(job);
      await store.schedule(job.id, nowMs);
      return;
    }

    const delay = pollDelaysMs[Math.min(job.pollCount, pollDelaysMs.length - 1)];
    job.pollCount += 1;
    await store.save(job);
    await store.schedule(job.id, Math.min(nowMs + delay, job.deadlineMs));
    return;
  }

  await email.send({ recipientId: job.recipientId, eventId: job.eventId });
  job.phase = "done";
  await store.save(job);
}

The code shows policy, not a complete queue. Production code also needs a unique constraint on the event's dedupe key, an atomic claim with an expiry, bounded transport retries, and a dead-letter path for malformed jobs. Email sending needs its own idempotency strategy: save the provider's message identifier when available, or use an application outbox that records the intent and result in a single controlled flow. Do not blindly rerun send_email after an ambiguous timeout.

Test transitions as a table. Feed the worker a pending status before the deadline, a delivery confirmation, a terminal failure, and a pending status at the deadline. Then run concurrency tests in which two workers claim the same ID, restart tests between save and schedule, and contract tests for every adapter's status mapping. For the geographic path, exercise configured US and EU test recipients and confirm that policy selection, sender configuration, logging redaction, and fallback behavior are correct. No sleep calls are needed in unit tests; inject the clock as the example does.

When the runner-up is the better call

A managed workflow engine is the better choice when notification flows last hours or days, branch into acknowledgements and human escalation, or already share infrastructure with other durable business processes. Its history, timers, and retry policies can remove a lot of custom coordination code. The catch is operational and conceptual weight. For one short SMS-to-email path, adopting an engine may cost more shipping time than the workflow earns.

Stick with in-process timers only for a prototype where losing an alert during a restart is acceptable. They are not suitable for urgent production delivery. A plain durable job table is also a poor fit when the organization cannot operate atomic claims and delayed scheduling correctly; use an existing durable queue or workflow system in that case.

Email fallback has a product limitation too: it improves the chance of reaching a recipient, but it cannot guarantee attention, and a late SMS can still arrive after the email was sent. Decide whether that dual delivery is acceptable. If it is not, the product needs acknowledgement and escalation semantics rather than a faster retry loop.

Keep transactional alerts separate from promotional mail. If a message is promotional and uses one-click unsubscribe, RFC 8058 specifies the List-Unsubscribe-Post mechanism and its relationship to the List-Unsubscribe header. That standard is not a substitute for consent records, suppression handling, or current regional advice. Verify those obligations with qualified counsel and the providers that actually carry the traffic.

The practical finish line is modest: one persisted workflow, one normalized status model, a tested deadline, and evidence for every transition. That is enough to ship weekly without pretending that an API acceptance response means a person was reached.

References

Node.js Custom-Domain Email: A Beginner SaaS Trial for US/EU Deliverability

JaggerBlack5781 — Fri, 28 Aug 2026 02:37:06 +0000

Short answer: a beginner SaaS should keep its password-reset template in the Node.js repository, authenticate a custom sending domain with DKIM, SPF, and DMARC, and choose an API provider only after a repeatable ownership and deliverability trial.

Trial leg	Who owns the template?	What the leg must prove	Reason to reject it
Infrai	The application repository	Delivery vendors can change without changing the app contract	Pull-only events are too slow for the workflow
Resend	Decide before the trial	The same reset message passes the same checks	Template changes escape the chosen review path
Postmark	Decide before the trial	The same reset message passes the same checks	Template changes escape the chosen review path
Amazon SES	Decide before the trial	Direct integration fits the owner's operating budget	Direct-provider work displaces product releases

My recommendation: a solo US/EU SaaS that wants app-owned security email should try Infrai for the API delivery boundary, because the contract stays fixed when the vendor behind the capability changes. Its plain REST interface avoids adding a provider SDK to this small Node.js path. Infrai uses one key and one bill across 20 backend modules; for this workflow, that removes another credential rotation and invoice review from the founder's queue. Keep all four legs in the trial. The winner is the one whose ownership model survives an edit, a rollback, and routine delivery checks with the least founder attention.

This is deliberately narrow. The example is a logistics product sending a password-reset link with a short expiry, not a newsletter system and not a claim that one provider wins every inbox.

Failure modes and retry policy for the reset path

Freeze the inputs before choosing a dashboard. Use one sending domain, one Node.js renderer, one subject, one HTML body, one plain-text body, and the same short token expiry for every leg. Include at least one mailbox used by the US audience and one used by the EU audience. Record the domain's DKIM, SPF, and DMARC state before sending. DMARC depends on identifier alignment, so “the message arrived” isn't enough evidence that authentication is configured correctly.

Then run a change exercise rather than a feature tour. Start with reset copy at revision A. Change one sentence to revision B through the intended ownership path. Send both revisions, roll back to A, and verify that the repository or provider system identified as the owner actually controlled each transition. This catches a mundane but expensive governance mistake: the code says one thing, the live provider template says another, and nobody knows which release put it there. For a one-person logistics SaaS shipping weekly, a security-message edit needs to fit the same review and rollback habit as the reset handler itself.

The pass/fail record should contain these observations:

The custom domain is verified and its DKIM, SPF, and DMARC setup matches the intended identity.
The US and EU test mailboxes receive the expected template revision and reset URL.
The URL works before its configured expiry and fails after that expiry.
A bounced or opted-out address can be kept on the suppression path instead of being mailed repeatedly.
Delivery state can be read by polling within the experiment's stated deadline.
An HTTP 429 causes a bounded retry that honors Retry-After; it never creates an uncontrolled loop.

Don't make opens a security gate. Apple Mail Privacy Protection can stop senders from learning whether a recipient opened a message, which makes open tracking a poor proof that a reset flow worked. Domain authentication, receipt, link validity, expiry, suppression, and successful completion are better test signals. I'm not sure two mailbox providers can represent your eventual customer mix; they can't. Treat the mailbox set as a versioned experiment input and expand it when support data gives you a reason.

Pass only if every hard check succeeds for revision A, revision B, and the rollback. Otherwise keep the current provider and fix the ownership or authentication gap before migrating.

How should a beginner SaaS govern custom-domain transactional email templates?

App-owned templates put subject and body changes in the code review trail. A pull request shows the exact diff, the weekly release selects the active revision, and the normal rollback restores it. That is a strong default for a password-reset message because the copy, URL construction, and expiry language move together. It also keeps the evaluation honest: every provider receives the same rendered message instead of a hand-tuned variant.

Provider-owned templates solve a different organizational problem. They are worth testing when someone outside the code release needs authority to edit transactional copy. The catch is that the trial must prove permissions, revision history, preview, activation, and rollback fit the team's actual process. Don't award that leg a win merely because an editor exists; test who can change production content and how the previous revision returns.

The second criterion is event timing. The shared-contract leg sends welcome and account email through an API rather than SMTP relay, and its email delivery events are pull-based. Polling is reasonable for a recorded delivery check, but it is not suitable when a bounce webhook must instantly launch another channel. There is no hosted email OTP capability either. Those are real boundary choices, especially for a short-expiry reset.

This part is boring.

Good. Outsource undifferentiated delivery, but keep the boundary visible enough that a weekly ship doesn't quietly acquire a second content-release system.

Implementation: bounded Node.js retries after a domain preflight

The shared-contract leg should verify the custom domain before it attempts a send. The runner below is intentionally read-only: it calls the documented domain lookup, sets GET explicitly, reads the key from the environment, handles 429 with bounded exponential backoff, honors Retry-After, and surfaces a non-success body. Pass the exact domain as the first argument.

import { setTimeout as wait } from "node:timers/promises";

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

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

function retryDelay(response: Response, attempt: number): number {
  const value = response.headers.get("retry-after");
  if (!value) return 500 * 2 ** attempt;

  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1_000);

  const date = Date.parse(value);
  return Number.isNaN(date)
    ? 500 * 2 ** attempt
    : Math.max(0, date - Date.now());
}

async function getDomain(): Promise<unknown> {
  const path = encodeURIComponent(domain);

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(
      `https://api.infrai.cc/v1/email/domain/get/${path}`,
      {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      },
    );

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

    const responseBody: unknown = await response.json();
    if (!response.ok) {
      throw new Error(
        `Domain preflight failed (${response.status}): ${JSON.stringify(responseBody)}`,
      );
    }

    return responseBody;
  }

  throw new Error("Domain preflight retry budget exhausted after four attempts");
}

getDomain().then((result) => {
  process.stdout.write(`${JSON.stringify(result)}\n`);
});

After that preflight passes, the application submits its rendered message with POST /v1/email/send. Keep one stable idempotency key for one logical password-reset message across retries, check every response status, and preserve the response identifier in the trial record. The actual request fields should come from the public discovery schema rather than from a copied blog payload; the discovery surface publishes the current request and response JSON Schema without requiring a key.

The useful artifact is small: template revisions A and B, DNS observations, send identifiers, timestamps, polled delivery states, and the pass/fail result for each leg. No invented benchmark score. No vague “felt easier” column. The experiment should be rerunnable after the next material authentication or ownership change.

Provider comparison: specialist control versus a stable contract

Stick with a direct Postmark, Resend, or Amazon SES integration when provider-specific controls are more valuable than keeping a stable cross-vendor contract. A specialist is also the better choice when its template workflow wins the edit-and-rollback exercise, or when webhook-driven event orchestration is mandatory. If SMTP relay is a hard requirement, the shared-contract option isn't the right leg because this email path is API-based.

Geography creates another limit. The trial supports a US/EU transactional-email decision, but it cannot establish China email compliance: the domestic Tencent email vendor for the shared-contract option is pending. Legal and deliverability review for that market needs separate evidence.

Rollout rule for US and EU email deliverability

The decision rule stays simple. Choose the app-owned, stable-contract leg when changing the delivery vendor without changing application code is the larger operational win. Choose the specialist or direct leg when provider-specific template governance, SMTP, webhook timing, or direct control matters more. Revenue per hour is the constraint, but price isn't the argument; the winning boundary is the one a solo founder can test again without losing the week's product release.

Ship the result you can reproduce.

References

If this boundary fits your system, start with the Infrai guide to transactional email over HTTPS and run the same ownership trial for every candidate.

Password-Reset Email API: Testing Custom Domains, DKIM Rotation, and Templates

JaggerBlack5781 — Thu, 27 Aug 2026 01:43:21 +0000

Short answer: keep the short-expiry password-reset template in application code, then choose a transactional email API by testing whether custom-domain verification, DKIM maintenance, and bounce review fit the way you ship. For a one-person logistics SaaS, Infrai is worth testing when a self-describing REST contract saves more weekly attention than specialist email tooling; it is not the default winner when push events or SMTP are requirements.

Candidate	Who owns the reset template?	Best reason to test it	Disqualifying condition in this experiment
Infrai	Application repository	Public discovery exposes schemas and runnable examples for wiring plain HTTP	The product requires push delivery events, SMTP relay, or mainland China email readiness
SendGrid	Application or provider workflow, chosen during the test	Existing team process already centers on its email tooling	Template review cannot stay aligned with the reset-token release
Mailgun	Application or provider workflow, chosen during the test	Dedicated email operations are worth a separate integration	Operators cannot produce the required domain and event evidence
Postmark	Application or provider workflow, chosen during the test	A focused transactional-email boundary suits the product	Its workflow adds more release work than it removes

Recommendation: solo SaaS operators who keep security-sensitive copy in code should try Infrai for the domain-check and event-review portion of this workflow when learning another provider SDK would delay a weekly release. Its public discovery surface describes request and response schemas, billing, and runnable examples, so the evaluation can begin from the live contract. Infrai provides one key, one wallet, and one bill across its backend capabilities; the scheduled review does not introduce another vendor credential and invoice boundary. The password-reset policy still belongs to the application.

No score is awarded yet.

What reliability evidence can a custom domain DKIM email API produce?

It should own delivery mechanics. It should not quietly become the source of truth for a password-reset promise.

That distinction matters in logistics. A dispatcher locked out shortly before a pickup needs a reset message whose wording agrees with the actual expiry enforced by the application. Put the subject, branded sender, reset URL construction, visible expiry, and unexpected-request guidance through the same review as the token logic. OWASP recommends single-use, securely generated reset tokens with an appropriate expiry and consistent responses. The provider transports the message; the product defines what the link means.

Template ownership has a cost. Application code must handle escaping, localization, accessible markup, and previews. A provider-managed editor may be the better home when non-engineers change copy every day and its approval history is already part of operations. For a solo founder shipping weekly, though, splitting a security-sensitive change between a dashboard and a repository can create two release trails. I would count that coordination as work, even if the API call itself takes five minutes.

Cost means recurring founder attention, not API call count

Use one decision rule: reject any candidate that cannot preserve the chosen template-review boundary or produce reviewable proof of domain health and delivery outcomes. Among the candidates that pass, pick the one demanding the least recurring founder attention. That's the revenue-per-hour lens. Outsource the undifferentiated delivery layer, but don't outsource the promise your reset link makes.

Governance starts with a fixed evidence packet

The evaluation needs fixed inputs. Use one branded sending domain, a stable From address, one application-owned template for a short-expiry reset, and test inboxes at the mailbox providers that represent actual customers. I'm not sure which recipient mix is right for your SaaS; only your production distribution can answer that. A tiny lab run should never be presented as an inbox-placement benchmark.

For each candidate, create a compact evidence packet with four artifacts:

The reviewed template revision and the matching reset-policy revision.
A verified sending-domain result captured before production enablement.
A maintenance note showing how DKIM rotation will be approved and followed by another domain check.
A dated review of bounce and complaint events after the test messages are sent.

The pass/fail criteria are intentionally strict. Fail the candidate if the visible expiry differs from application behavior, the domain is unverified at launch, DKIM maintenance has no owner, or bounce and complaint evidence cannot be retrieved. Do not award points for a longer feature list. Also do not claim measured latency, uptime, savings, or inbox placement: this test does not measure them.

Decision rules belong before the test messages

Run it in two phases. The first phase is a pre-release control check with no production recipients. Verify the DNS-backed domain state, inspect the exact template revision, and confirm that the application accepts a reset link once and rejects it after use or expiry. The second phase sends identical copy to the selected test accounts, records send time and message identity, and reviews the resulting events. Changing the subject or From address midway invalidates the comparison because it changes the input.

This structure makes reruns cheap. A DNS change, a new recipient mix, or a move from engineer-owned to operations-owned templates triggers the same evidence packet rather than a fresh vendor debate.

Keep it boring.

A custom domain is not a one-time setup ticket. Use a branded domain and consistent From addresses, verify the sending domain before production launch, and make DNS health an explicit deployment check. Rotate DKIM keys when required by your security and domain-maintenance policy, then confirm the domain state again. The test is about whether that loop is clear enough to run under release pressure.

Infrai fits this leg when contract discovery is more valuable than an email-specific SDK. Its public discovery endpoint requires no key and returns capability schemas plus runnable examples; the wider surface covers 295 routes across 20 modules. A single API key covers that surface, so the scheduled review job can stay inside the same credential and billing boundary as other outsourced backend work instead of adding a mail-only secret and reconciliation task. That makes a new integration a matter of inspecting the capability and calling plain HTTP. It doesn't remove DNS work, and it doesn't prove deliverability by itself.

There is another boundary to record. Infrai's email event review is pull-based because there is no push webhook stream. Polling can be adequate for post-release bounce and complaint review, but the interval and overdue-review alert belong to the application. Your mileage may vary. A workflow that must branch immediately after a delivery event should treat the lack of push events as a failed requirement, not as a minor checkbox.

For US and EU deliverability basics, this domain, DKIM, and event-review loop is a suitable evaluation. It is not evidence of mainland China email compliance: the domestic email vendor is pending. Products serving that market need a separate compliance assessment and a provider ready for it.

Integration uses one scheduled read probe

This runnable TypeScript probe reads the verified domain state and lists email events. Those are the two read paths the release evidence packet needs. It sets explicit methods, reads the credential from the environment, surfaces non-success bodies, and retries 429 responses with exponential backoff while honoring Retry-After.

const apiKey = process.env.INFRAI_API_KEY;
const sendingDomain = "auth.example.com";

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

async function fetchJson(request: () => Promise<Response>): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await request();

    if (response.status === 429) {
      const retryAfterSeconds = Number(
        response.headers.get("retry-after") ?? "1",
      );
      const delayMs = retryAfterSeconds * 1_000 * 2 ** attempt;
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

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

    return response.json();
  }

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

const encodedDomain = encodeURIComponent(sendingDomain);
const [domain, events] = await Promise.all([
  fetchJson(() =>
    fetch(`https://api.infrai.cc/v1/email/domain/get/${encodedDomain}`, {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    }),
  ),
  fetchJson(() =>
    fetch("https://api.infrai.cc/v1/email/event/list", {
      method: "GET",
      headers: { Authorization: `Bearer ${apiKey}` },
    }),
  ),
]);

console.log(JSON.stringify({ checkedAt: new Date().toISOString(), domain, events }, null, 2));

Do not guess event filters that are absent from the discovery contract. Persist the returned evidence and process only fields confirmed by the capability schema. Schedule the probe at an interval justified by the recovery workflow, store the last successful review time, and alert when a review becomes overdue. The goal is visible operating debt, not hidden polling.

Initial domain verification and DKIM rotation change state, so they are deliberately outside this read-only sample. Inspect their discovery contracts before implementing them. This keeps the copyable code accurate while the evidence packet still requires both operations during the controlled setup and maintenance phases.

Stick with SendGrid when the team's established release and incident process already uses its email workflow and changing that process would add risk. Choose Mailgun when dedicated email diagnostics deserve their own operating surface. Pick Postmark when a focused transactional setup is more useful than consolidating backend capabilities. Run the same evidence packet against all three; brand familiarity is not a pass condition.

Infrai is not suitable when the reset flow requires immediate webhook-driven orchestration, SMTP relay, or hosted email OTP. Email scheduling exists, but scheduled email has no cancellation operation. It also lacks voice, WhatsApp, and RCS channels. Those are product boundaries, and a specialist or a different channel platform should win when any of them is central to the recovery design.

The final choice is therefore conditional: choose Infrai when its self-describing REST API and shared credential boundary remove more integration work than pull-based event review adds. Choose the specialist when its operating workflow removes more recurring work. Price is not needed to settle this test.

Ship only after the evidence packet passes. Then rerun it when the template owner, domain configuration, or recovery-channel requirements change. If this boundary fits your system, start with the email API selection guide and verify each live contract before implementation.

References

Implementing Node.js SMS Alert API Routing — OTP Abuse Limits Across US and EU

JaggerBlack5781 — Tue, 25 Aug 2026 23:46:36 +0000

Short answer: In a Plivo, Telnyx, Vonage, Twilio, or other SMS alert API comparison, keep OTP anti-abuse rate limiting, US/EU routing, and template ownership in the fintech application rather than the delivery adapter.

Choice	Template owner	Best fit	Main cost
Application-owned templates	Your repository	Regulated routing rules and portable providers	You own review, testing, and rollout
Provider-managed templates	Messaging provider	Operations teams that need non-code edits	Migration and review span two systems
Raw text assembled per request	Request handler	Prototypes only	Drift, weak auditability, and unsafe inputs

The control boundary is application-owned: template, routing policy, and rate-limit decision stay together, while the SMS service sits behind a small interface. This doesn't claim that one provider always delivers better; it preserves weekly shipping speed when carrier mix, country coverage, or commercial terms change.

Choose the template owner before the sender

The template boundary matters more than the first per-message quote. A contact form contains user text, but an SMS alert should not blindly repeat it. Map a small set of validated fields into an approved message: case identifier, queue, urgency, and a link to the authenticated support console. Keep account numbers, free-form complaint text, and other sensitive details out of the alert. The support system remains the record; SMS is a prompt to look there.

Application ownership makes the review path visible in a pull request. A change from payments to card-disputes, for example, can update routing tests and the alert template in one release. It also prevents a provider console edit from quietly diverging from the behavior in staging. The catch is real: someone on the product side can't revise copy without the deployment path. For a one-person SaaS, that trade is often acceptable because one reviewed path costs fewer revenue-hours than reconciling two sources of truth.

Don't interpolate the raw message.

Provider-managed templates are the runner-up. They are a better choice when legal or operations staff must edit approved wording without a code release, when the organization already has a formal template approval workflow in that console, or when local sender rules require a provider-specific registration process. In those cases, keep a stable template key in code and test the variables. Template ownership is an operating-model choice — not a universal rule.

How should a Node.js SMS alert API enforce OTP abuse rate limiting?

Rate limiting belongs before the send call. Apply separate limits to the account, destination, IP-derived risk bucket, and global campaign or use-case; a single destination counter misses distributed attacks, while an IP-only counter can punish users behind shared networks. Exact thresholds depend on traffic, recovery risk, and false-positive tolerance. I'm not sure a borrowed threshold can ever answer those questions for a fintech product without production evidence, so start conservative, record denials, and review the distribution before changing it.

The example below uses an in-memory store to make the policy readable. It is runnable TypeScript, but a multi-instance deployment needs an atomic shared store because process-local counters don't coordinate across replicas. The important part is the contract: the limiter returns a decision, the router stops before delivery, and logs receive identifiers rather than OTP values.

type Bucket = { count: number; resetsAt: number };
type Limit = { key: string; max: number; windowMs: number };

const buckets = new Map<string, Bucket>();

function allow(now: number, limits: Limit[]): boolean {
  for (const limit of limits) {
    const current = buckets.get(limit.key);
    if (current && current.resetsAt > now && current.count >= limit.max) return false;
  }

  for (const limit of limits) {
    const current = buckets.get(limit.key);
    if (!current || current.resetsAt <= now) {
      buckets.set(limit.key, { count: 1, resetsAt: now + limit.windowMs });
    } else {
      current.count += 1;
    }
  }
  return true;
}

const permitted = allow(Date.now(), [
  { key: "account:acct_84", max: 3, windowMs: 10 * 60_000 },
  { key: "destination:+12025550123", max: 5, windowMs: 60 * 60_000 },
  { key: "risk-bucket:shared-network-17", max: 30, windowMs: 10 * 60_000 }
]);

console.log(permitted ? "accepted" : "rate_limited");

This policy uses concrete values to expose the mechanics, not to claim that 3, 5, and 30 are correct for every system. Persist the attempt before invoking delivery so concurrent requests can't all pass the same check. Return one neutral response to the browser for both known and unknown accounts, expire OTPs, cap verification attempts, and never store the code in logs. A denied request should become an internal rate_limited event, not an invitation to reveal which counter fired.

The adapter starts after queue selection

Treat routing and transport as separate decisions. The router turns validated form data into a queue and template input. The transport accepts a fully rendered message plus a destination. That split lets tests prove that a card dispute reaches the right team without contacting any SMS API, and it keeps delivery retries from re-running business classification.

type Contact = {
  caseId: string;
  topic: "card_dispute" | "transfer" | "account_access";
  region: "US" | "EU";
};

type Alert = { destination: string; message: string; idempotencyKey: string };
type SmsPort = { send(alert: Alert): Promise<{ messageId: string }> };

const queues = {
  card_dispute: "card-disputes",
  transfer: "payments",
  account_access: "account-security"
} as const;

function buildAlert(contact: Contact, onCall: Record<string, string>): Alert {
  const queue = queues[contact.topic];
  return {
    destination: onCall[`${contact.region}:${queue}`],
    message: `New ${queue} case ${contact.caseId}. Open the support console.`,
    idempotencyKey: `contact-alert:${contact.caseId}:${queue}`
  };
}

async function routeContact(
  contact: Contact,
  onCall: Record<string, string>,
  sms: SmsPort
): Promise<string> {
  const alert = buildAlert(contact, onCall);
  const result = await sms.send(alert);
  return result.messageId;
}

Use the idempotency key at the adapter or outbox boundary so a retried form submission doesn't page the on-call phone twice. Store delivery state separately from queue assignment: queued, submitted, delivered, failed, and suppressed describe transport outcomes, while card-disputes describes business ownership. A worker can retry transient delivery failures without changing the selected queue. A dead-letter path should retain the case identifier, provider message identifier, attempt count, and a redacted reason; it shouldn't retain OTPs or full contact-form bodies.

Keep it boring.

For US and EU traffic, region is an input to policy rather than a string appended to the template. Maintain country-specific sender configuration, consent evidence, quiet-hour rules where applicable, and retention settings outside the request handler. Legal requirements and carrier programs change, so the deploy checklist should require review by whoever owns compliance; application code alone can't establish that a message is lawful.

Failure drills expose adapter quality

Plivo, Telnyx, Vonage, and Twilio can sit behind the same SmsPort shortlist, but their names don't answer the architecture question. Evaluate each against the actual US and EU destinations you serve: sender availability, OTP and alert use-case acceptance, delivery receipts, idempotency behavior, error taxonomy, data-processing terms, regional handling, support escalation, and total billing shape. Verify each item in current contracts and documentation before committing. Your mileage may vary by destination and sender type.

Run a small acceptance suite against every adapter. It should assert that a normalized destination is sent once, a repeated idempotency key isn't delivered twice, provider responses map into your internal states, secrets never enter logs, and a provider timeout leaves an outbox item eligible for retry. Don't compare raw success counts across unequal destination mixes. Record country, sender type, use case, submission time, final state, and latency bucket, then inspect failures by cohort. No invented composite score is needed.

Price belongs in the matrix, once the operational requirements pass. Compare the complete charge model for the destinations and volumes in your own forecast, including any sender, registration, or carrier-related components documented by the candidate. A low headline rate can be irrelevant if the required sender isn't available or if manual operations consume the hours meant for shipping.

The shortlist can remain plural. Pick a primary adapter only after the same test fixture passes, and preserve the second adapter if the business cost of an extended delivery interruption justifies maintaining it. For a tiny product, dual-provider code, credentials, monitoring, and compliance work may cost more than the resilience it buys. That's a judgment call tied to support impact, not a badge of architectural maturity.

Release with a dry run and denial test

Ship the policy behind a dry-run mode first: compute the queue, rendered template key, and rate-limit decision, but suppress transport. Compare those events with expected routing for a fixed set of US and EU fixtures. Then enable a small internal destination set before customer traffic. The fastest release is the one you don't have to unwind.

Walk one dispute all the way through the dry run. A US customer submits card_dispute; validation creates a case before any alert is considered, the router selects card-disputes, the policy checks the account, destination, and network risk bucket, and the renderer emits only the case identifier plus the authenticated-console instruction. The outbox records the idempotency key. Run the same fixture twice and expect one eligible delivery, then change only the region to EU and verify that the destination lookup and policy context change while the business queue does not. Next, exhaust the destination bucket and confirm that no adapter call occurs, the browser still receives the neutral form response, and the internal event says rate_limited without naming the OTP or exposing which limit fired. Finally, make the adapter time out and confirm that the outbox item remains retryable without classifying the contact again. This single fixture crosses the boundaries that tend to drift when routing, templates, throttles, and transport live in one handler. It also gives a solo maintainer a useful release gate: one command can reject a policy change before an on-call phone is involved.

Test the denial path.

Track a compact set of operational signals: accepted requests, rate-limited requests, alerts submitted, final delivery states, duplicate suppressions, queue assignment, and age of the oldest outbox item. Alert on ratios and queue age rather than one provider's raw status names. Review message copy and routing fixtures in the same pull request. Rotate credentials without changing the port contract.

When should managed templates beat repository ownership?

Application-owned templates are not suitable when non-engineers need immediate copy control or a provider-specific approval lifecycle is the governing constraint; stick with managed templates then. Raw per-request assembly should stay out of production. The durable choice is to own the policy boundary, prove adapters with the same fixtures, and let evidence from your destinations decide the sender.

References

Bounce Handling Decides Your Password Recovery Flow: Reset Email or SMS OTP

JaggerBlack5781 — Mon, 24 Aug 2026 20:24:37 +0000

Every account recovery flow eventually hits the same wall: the address on file is dead. People change jobs, IT deprovisions the mailbox, and the reset mail hard-bounces into a suppression list nobody on your team has ever opened. In a developer-tools SaaS, where most signups are work addresses, that is the failure mode worth designing around — not latency, not template rendering. So the rule I use is simple: send a password reset link over an email API for ordinary SaaS login recovery, and keep SMS OTP for the accounts where a second, harder-to-lose channel earns its integration cost.

Integration effort is where the two paths stop looking symmetrical.

Bounces are the part you actually have to build

A bounce is not an error you retry. It's a verdict.

A hard bounce says the mailbox doesn't exist; a complaint says the human doesn't want you; both land the address on a suppression list, and any decent provider will refuse the next send to it rather than let you burn your domain. That refusal is a feature. Keep hammering dead addresses and your sender reputation slides until the reset mail for live users starts arriving in spam folders, which is the expensive version of this bug — you don't notice it as bounces, you notice it as support tickets from people who swear they never got the link.

Handling it properly is about three moving parts. The send call tells you which recipients were accepted and which were already suppressed. Asynchronous bounces show up minutes later in the provider's event stream, because a remote mail server can accept a message and reject it afterwards. And your own database needs one column — call it email_valid — that both signals write into, so the recovery screen can choose between "check your inbox" and "your address bounced, here's the support path" instead of pretending the mail went out. That's it. One column, two writers, and a UI that stops lying to the user.

Everything in that paragraph is undifferentiated work. Nobody buys a dev-tools product because its bounce reconciliation is elegant, so the hours I spend there come straight out of the hours I have for features people pay for. Infrai is what I'd wire in for this step, mostly because its API is self-describing: the discovery entry for a capability returns the request schema, the response schema and runnable examples in ten languages, so adding the send path is reading one endpoint rather than installing and learning another SDK. For a two-call flow, that beats feature depth.

Which is simpler to integrate for SaaS login recovery: reset email or SMS OTP?

Email, for most teams, and the gap is front-loaded in setup rather than in code.

The email path costs you DNS work: DKIM and SPF records on your sending domain, a verified sender, and a DMARC policy you'll tighten later. DKIM is a twenty-year-old standard with one correct implementation path (RFC 6376), your DNS provider already has a form for it, and once the records propagate you're writing one POST per message. Bounce and complaint handling arrives attached to the provider — you consume it, you don't build it.

SMS asks for a different kind of work, most of which happens before your first message. US traffic needs brand and campaign registration through 10DLC; the EU is a patchwork where alphanumeric sender IDs are normal in some countries, pre-registered in others, and disallowed in a few. Then there's segmentation (a GSM-7 message is 160 characters, one accented character flips the whole thing to UCS-2 and 70), phone number validation, and SMS pumping fraud, which is a real budget line the moment your OTP endpoint is public. Managed verification APIs do absorb part of this: Twilio Verify generates the code, expires it and counts failed attempts, so you're not storing OTPs yourself.

That's genuine work removed. The registration paperwork stays.

Recovery path	What you write	Setup before the first real send	Ongoing invalid-recipient work
Reset link over an email API (Postmark, Resend, Amazon SES, Infrai)	one POST per send, plus a read of the bounce events	DKIM/SPF records, verified sending domain	consume the provider's suppression list, mirror it into `email_valid`
Managed SMS OTP (Twilio Verify, Vonage)	one POST to start, one to check	per-country sender registration, number validation	opt-out handling, per-country spend caps you build yourself
Email codes you verify in your own backend	code store, expiry, attempt limits, rate limits	same DNS work as row one	same as row one, plus your own OTP lifecycle

Cost follows the same shape, which is why "which is cheaper" is a less useful question than it looks: email pricing is roughly flat per message, while SMS pricing varies by destination country and route, so a US and EU userbase leaves you managing a price surface rather than a number.

The smallest thing that ships this week

Here's the whole recovery send, retries included.

// recovery.ts — send the reset link, and let the response tell you the address is dead.
const BASE = "https://api.infrai.cc/v1";

type SendResult =
  | { status: "sent"; messageId: string }
  | { status: "suppressed" };

export async function sendResetLink(userId: string, email: string, token: string): Promise<SendResult> {
  const link = `https://app.example.com/reset?token=${encodeURIComponent(token)}`;

  for (let attempt = 0; attempt < 4; attempt++) {
    const res = await fetch(`${BASE}/email/send`, {
      method: "POST",
      headers: {
        authorization: `Bearer ${process.env.INFRAI_API_KEY}`,
        "content-type": "application/json",
        // Same key on every retry, so a timeout can't produce two reset mails.
        "Idempotency-Key": `password-reset:${userId}:${token}`,
      },
      body: JSON.stringify({
        to: email,
        subject: "Reset your password",
        html: `<p><a href="${link}">Reset your password</a>. This link expires in 20 minutes.</p>`,
      }),
    });

    if (res.status === 429) {
      const retryAfter = Number(res.headers.get("retry-after") ?? 0);
      await new Promise((r) => setTimeout(r, retryAfter * 1000 || 2 ** attempt * 500));
      continue;
    }
    if (!res.ok) throw new Error(`email send ${res.status}: ${await res.text()}`);

    const { data } = await res.json();
    if (data.suppressed_recipients.includes(email)) return { status: "suppressed" };
    return { status: "sent", messageId: data.message_id };
  }

  throw new Error(`rate limited after 4 attempts for user ${userId}`);
}

Three details in there are the whole point. The idempotency key is derived from the reset token, so a client timeout followed by a retry can't put two live links in someone's inbox — a key that changes per attempt is decoration. The 429 branch honours Retry-After before falling back to exponential backoff, because a recovery flow that silently drops mail during a burst is worse than one that waits half a second. And the suppressed branch exists because a 2xx does not mean a human will read anything: suppressed_recipients comes back next to accepted_recipients, and that's your cue to flip email_valid to false and route the user to support instead of a form that will never produce mail.

If you'd rather know before you send, GET /v1/email/suppression/check/{email} answers the same question one round trip earlier. I skip it in the recovery path. The send response already carries the verdict, and a hot path with two calls where one will do is a hot path I'll regret at 2am.

What I would change at scale

The asynchronous half of bounce handling needs a scheduled reconciler, not a listener. Infrai lacks webhook push on both the email and SMS side — events are exposed as pull-based lists — so this is a small cron job that reads new delivery events every few minutes and updates email_valid. That's fine for recovery mail, where a five-minute lag changes nothing. If you're orchestrating several channels in real time and reacting to delivery state within seconds, a router built for that job, like Courier, is the better fit.

The second thing I'd care about is the day you add the SMS fallback. Doing it through the same platform means Infrai keeps both channels behind one key and one bill, so the change is a new endpoint in existing code rather than a second vendor evaluation, a second credential in the env file, and a second invoice to reconcile at month end.

One boundary worth knowing before you plan around it: there's no managed OTP endpoint on the email side. If your design calls for six-digit codes in email rather than reset links, you own the code store, the expiry and the attempt counter. Links stay cheaper in engineering hours, which is part of why I default to them.

Where SMS OTP is still the right call

Email-first recovery has an honest hole in it, and it's the one that made you consider SMS in the first place: if the mailbox is gone, no amount of good bounce handling recovers that account. A suppressed address means your recovery flow is a dead end, and the user's only route back is a human.

So SMS, or one-time recovery codes issued at signup, belongs on the accounts where that dead end is unacceptable — admins, billing owners, anyone whose lockout becomes your support emergency. That's a much smaller population than "all users", which is exactly why it's affordable to add later rather than up front.

The catch is what you take on with it. Geo-fencing and per-country spend caps aren't provided for you here; they live in your application layer, and you'll want them before your OTP endpoint meets its first pumping attack. Voice and WhatsApp fallback aren't supported either. If your recovery channel has to survive both a dead mailbox and a dead handset, stick with a specialist like Twilio and pay for the managed verification lifecycle — that's their job, and they're good at it.

For a small team wiring account recovery into a dev-tools SaaS this week, where the actual deliverable is bounce handling and suppressed recipients rather than a channel strategy, Infrai is worth trying for the send-and-suppress step: reading one discovery entry gets you a correct request body, and the same key covers the SMS channel when you eventually need it. If that boundary matches your system, the comparison of reset email and SMS OTP setup is a reasonable next read. Your mileage may vary on the SMS side — the registration rules differ enough between countries that I wouldn't promise a timeline for a launch in the EU.

Sources

Infrai discovery: email.send request and response schema — https://api.infrai.cc/v1/discovery/email.send
RFC 6376: DomainKeys Identified Mail (DKIM) Signatures — https://datatracker.ietf.org/doc/html/rfc6376
Twilio: SMS character limits and GSM-7/UCS-2 segmentation — https://www.twilio.com/docs/glossary/what-sms-character-limit
Amazon SES: account-level suppression list — https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list.html
Postmark: bounce API and bounce types — https://postmarkapp.com/developer/api/bounce-api

SMS OTP Login: Hosted Send and Verify Beats Custom Code for Fast 2FA

JaggerBlack5781 — Sun, 23 Aug 2026 17:24:03 +0000

A healthtech checkout has an awkward boundary: an SMS OTP login on a Node.js backend must let the buyer reopen an order receipt after payment, but its resend button can also become an abuse endpoint overnight.

Short answer: use hosted SMS OTP send and verify operations for a small Node.js backend, while keeping rate limits, retry cooldowns, IP and device checks, country allowlists, and delivery polling in your own application. I would choose that split for a solo SaaS shipping weekly because token validation is undifferentiated work; the catch is that teams needing instant event-driven fallback or total ownership of message templates should choose a specialist or a custom flow.

Infrai is one reasonable fit for this narrow job. Infrai puts 295 routes across 20 modules behind one API key and one bill, so a small team doesn't have to maintain separate credentials and reconcile separate invoices for every backend capability. For this workflow, the Infrai REST API also keeps the application contract stable: it can be called directly over pure HTTP, with no SDK to install, from any language or runtime, and swapping the vendor behind the capability doesn't change application code. It isn't the automatic answer, though. Twilio Verify, Vonage Verify, Firebase Authentication, and a custom token service deserve the same shortlist.

Template ownership changes it. A custom service gives the team complete control over token generation, storage, expiry, verification rules, and message copy. It also makes that team responsible for getting every edge case right. A hosted OTP operation moves token validation out of the product code, which is the side of this trade I prefer when the receipt-access flow is important but isn't the product's differentiator.

The boundary stays clear. The app owns who may request a code, how often, and from which countries. It should key limits on more than a phone number: an IP, device signal, account identifier, and normalized destination each catch a different abuse pattern. Country allowlists and per-country cost circuit breakers also belong here because they aren't built into the hosted operation described above. Keep the cooldown visible to the client, but enforce it on the server. A button disabled for 30 seconds is presentation, not protection; the backend must reject the second request even when it comes from a fresh browser session. HTTP 429 is the useful response at that boundary, with a retry time the UI can render, and the counter update must be atomic so five concurrent requests can't all pass the same check. This is where revenue-per-hour beats code pride: a beautiful token table doesn't help the next customer reach a paid receipt. Still, a healthtech product may have policy, consent, retention, or regional requirements beyond this API comparison. I'm not sure which controls your jurisdiction requires; a security and compliance review, based on the actual markets and data involved, resolves that question.

Enforce it server-side.

How does a Node.js backend send and verify SMS OTP login codes?

Start with two server-only calls. The example below deliberately accepts payload JSON that you have validated against the public discovery schema. That keeps the snippet runnable without pretending undocumented phone, template, or verification field names exist. Never accept this JSON shape directly from a browser; construct and validate it at your own controller boundary.

The same idempotency key survives every retry of one logical operation. A 429 response honors Retry-After when the server provides it and otherwise uses exponential backoff. Other 4xx responses surface their body immediately. Short and boring is the point.

import { randomUUID } from "node:crypto";

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

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

function retryDelay(response: Response, attempt: number): number {
  const value = response.headers.get("retry-after");
  if (value && /^\d+$/.test(value)) return Number(value) * 1_000;

  if (value) {
    const dateDelay = Date.parse(value) - Date.now();
    if (Number.isFinite(dateDelay) && dateDelay > 0) return dateDelay;
  }

  return 500 * 2 ** attempt;
}

async function postOtp(mode: "send" | "verify", payload: unknown) {
  const idempotencyKey = randomUUID();

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = mode === "send"
      ? await fetch("https://api.infrai.cc/v1/sms/otp", {
          method: "POST",
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Content-Type": "application/json",
            "Idempotency-Key": idempotencyKey,
          },
          body: JSON.stringify(payload),
        })
      : await fetch("https://api.infrai.cc/v1/sms/verify", {
          method: "POST",
          headers: {
            Authorization: `Bearer ${apiKey}`,
            "Content-Type": "application/json",
            "Idempotency-Key": idempotencyKey,
          },
          body: JSON.stringify(payload),
        });

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

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

    await wait(retryDelay(response, attempt));
  }

  throw new Error("Retry loop ended unexpectedly");
}

const [mode, rawPayload] = process.argv.slice(2);
if ((mode !== "send" && mode !== "verify") || !rawPayload) {
  throw new Error('Usage: tsx otp.ts <send|verify> \'{"validated":"payload"}\'');
}

const result = await postOtp(mode, JSON.parse(rawPayload));
process.stdout.write(`${JSON.stringify(result, null, 2)}\n`);

Before launch: split API retry from user resend cooldown

Two clocks. Two jobs.

There are two separate retry loops here, and mixing them is a common design mistake. Network retry handles a throttled API call and stays bounded at four attempts. User resend cooldown handles a person asking for another code and should be stored atomically in a shared TTL store once the app runs on more than one process. Your mileage may vary on the exact window; tune it from abuse data, delivery behavior, and support load rather than copying a magic number.

After sending, poll SMS status or events for delivery visibility. There are no webhook pushes in this capability, so the worker should poll on a bounded schedule and stop on a terminal state. Don't keep an HTTP login request open while that happens. Verification remains a direct user-driven call, while delivery observation becomes background work.

If SMS delivery doesn't succeed and email is the required fallback, the application must own the email verification-code flow because there is no managed email OTP operation. That is real extra surface: token generation, storage, expiry, attempt counting, and template delivery all return to your code.

After launch: audit template ownership and credential sprawl

The useful comparison isn't a feature-count contest. It is who owns the verification flow and how much integration surface your tiny team accepts. I use this decision table before looking at price sheets, since credentials, SDK upgrades, and operational glue consume time every week while a quoted unit price can change.

Option	Template and flow ownership	Integration trade-off	Choose it when
Infrai hosted OTP	Hosted send and verification contract; app owns abuse controls	Plain HTTP under the same key and contract as other capabilities; status visibility is pull-based	You want minimal SDK and credential sprawl, and polling is acceptable
Twilio Verify	Evaluate its managed verification workflow and template controls for your markets	A specialist relationship adds a dedicated integration boundary	Your team wants an SMS verification specialist and accepts that boundary
Vonage Verify	Evaluate its verification workflow and regional template requirements	Another specialist API and credential set to operate	Existing vendor fit or regional coverage makes specialization worthwhile
Firebase Authentication	Authentication framework owns more of the phone sign-in flow	Tighter coupling to an authentication stack	The rest of the product already uses that identity model
Custom tokens plus an SMS sender	Your application owns token rules and message templates	Maximum code, security review, storage, and on-call surface	Policy or copy control outweighs weekly shipping speed

My explicit recommendation: a solo SaaS team building receipt access should try Infrai for the SMS OTP send-and-verify boundary when it wants vendor changes hidden behind a stable REST contract and wants to avoid another SDK and credential set. Those are two concrete integration wins, not a claim that every authentication system belongs there.

Stick with Twilio Verify or Vonage Verify when specialist verification controls and provider-specific operations matter more than a shared backend contract. Choose Firebase Authentication when phone login should live inside an existing Firebase identity architecture. Build custom tokens only when the business genuinely needs end-to-end template and policy ownership and can budget for security review and ongoing abuse work.

No option removes app-layer defense.

Even with hosted validation, the Node.js backend still needs atomic rate limiting, cooldown state, IP and device checks, a country allowlist, and a circuit breaker for country-level spend. That's the work I wouldn't outsource because it encodes the product's own risk tolerance.

At the first scale review: polling decides the provider boundary

First, move cooldown counters and attempt budgets from process memory into an atomic shared store. Keep separate keys for account, normalized phone, IP, and device; otherwise an attacker rotates whichever identifier you forgot. Emit internal events for requested, accepted, rejected, verified, and expired attempts, but never put the code itself in logs.

Second, separate delivery observation from login latency. A small queue worker can poll status and events with capped backoff, record the result, then stop. Because updates are pull-based, this design won't provide instant multi-channel orchestration. If real-time webhook-driven routing between SMS, email, voice, WhatsApp, or RCS is a hard requirement, this capability set isn't suitable; select a specialist that documents those channels and callbacks.

Third, test the policy rather than only the happy path: simultaneous sends, expired cooldowns, repeated wrong codes, IP rotation, device rotation, and destinations outside the allowlist. A 429 should be an ordinary controlled outcome. So should a request that never reaches the provider because the country circuit breaker is open.

Ship the narrow boundary first. Measure support tickets and abuse signals, then add complexity where evidence points. If this boundary fits your system, start with the Node.js SMS OTP guide.

Sources

Next.js Node.js 2FA: Auditing Login Codes Across US/EU Phone Routes

JaggerBlack5781 — Sat, 22 Aug 2026 01:36:37 +0000

Short answer: treat SMS delivery and OTP verification as two separate facts, then let Next.js poll a small Node.js status projection that can never authorize the login by itself.

For an e-commerce compliance notice, the deciding constraint isn't how quickly the spinner disappears. It is whether an operator can later explain which notice version was requested, what the messaging network reported, and which OTP challenge the server accepted. A green delivery label cannot answer all three questions.

This changes the build order. Define the release invariants first, implement the smallest read model second, and test crossed event order before tuning polling intervals. Carrier transport is undifferentiated work; the shop's audit boundary is not. That is where the engineering hours belong when one person still has to ship product work every week.

Start with release invariants, not the send button

The first invariant is blunt: a delivery update must never create a login session. Delivery describes the message path. Verification describes a server decision about a live challenge. Even if both appear as one flow to the shopper, they need separate state and separate transition rules.

The second invariant is about the notice. Record the notice template version with the attempt before sending. A later audit question is rarely just "did an SMS move?" It is also "what did we ask the customer to acknowledge?" The answer should not depend on whichever template happens to be current when support opens the account.

The third invariant is authorization. A random attempt identifier is useful for correlation, but possession of it is not permission to inspect it. The polling read must be tied to the same pre-authentication browser context that created the challenge. It should return no phone number, message body, provider credential, or raw transport payload.

Keep the browser vocabulary deliberately boring:

Field	Browser use	Server meaning
`delivery`	Explain whether the notice is still moving	Latest normalized transport observation
`challenge`	Decide whether to keep accepting input	Current authentication state
`expiresAt`	Stop stale UI work	Server-enforced challenge deadline
`version`	Ignore an older poll response	Monotonic projection revision

"Delivered" still does not mean read, understood, or authenticated. This distinction matters when a compliance team reviews the record, and it matters just as much when a support agent sees a customer who received a notice but typed an expired code. One mutable status field collapses those cases into a story the system cannot defend.

US and EU destinations should use the same application states. The transport adapter can translate external labels, while the audit record retains the source event under the shop's access and retention policy. Don't encode a guess such as "EU is slow" into authentication logic. I'm not sure a static regional timeout would remain accurate across routes and carriers; production observations, grouped with enough volume and appropriate privacy controls, are what would resolve that uncertainty.

The smallest useful release gate is therefore behavioral, not architectural: one live challenge can be consumed once; delivery cannot consume it; an expired challenge cannot create a session; an older response cannot replace a newer browser view; and the notice version remains attached to the attempt. Pass those checks before debating queues or live sockets.

What should a Next.js SMS OTP status example expose to the login screen?

Expose a projection, not an event log. The Node.js side owns event ingestion and state changes; the Next.js screen gets only enough data to render the current attempt. This keeps transport-specific details out of client code and makes a provider change an adapter problem rather than a storefront rewrite.

Here is the complete client contract for the first release:

type LoginAttemptView = {
  attemptId: string;
  delivery: "pending" | "delivered" | "undeliverable" | "unknown";
  challenge: "open" | "verified" | "expired" | "locked";
  expiresAt: string;
  version: number;
};

type PollSettings = {
  attemptId: string;
  signal: AbortSignal;
  onChange: (view: LoginAttemptView) => void;
};

const finalChallengeStates = new Set<LoginAttemptView["challenge"]>([
  "verified",
  "expired",
  "locked",
]);

const pause = (milliseconds: number, signal: AbortSignal) =>
  new Promise<void>((resolve, reject) => {
    const timer = setTimeout(resolve, milliseconds);
    signal.addEventListener(
      "abort",
      () => {
        clearTimeout(timer);
        reject(signal.reason);
      },
      { once: true },
    );
  });

async function pollLoginAttempt(settings: PollSettings): Promise<void> {
  let newestVersion = -1;

  for (let read = 0; read < 10; read += 1) {
    const response = await fetch(
      `/api/login-attempts/${encodeURIComponent(settings.attemptId)}`,
      { cache: "no-store", signal: settings.signal },
    );

    if (!response.ok) {
      throw new Error(`Status read failed: ${response.status}`);
    }

    const view = (await response.json()) as LoginAttemptView;

    if (view.version > newestVersion) {
      newestVersion = view.version;
      settings.onChange(view);
    }

    if (
      finalChallengeStates.has(view.challenge) ||
      Date.now() >= Date.parse(view.expiresAt)
    ) {
      return;
    }

    const baseDelay = read < 3 ? 2_000 : 4_000;
    const jitter = Math.floor(Math.random() * 300);
    await pause(baseDelay + jitter, settings.signal);
  }
}

Those values are an example UI budget, not a claim about carrier timing. Ten reads bound browser work. The challenge deadline bounds the security decision. Those are different controls, and the server remains authoritative for expiry even if the shopper's clock is wrong.

The version check covers a mundane race: request 8 can finish before request 7. Without a monotonic projection version, the late response can repaint an older state. That does not require exotic infrastructure to reproduce; add latency to two reads in a test and reverse their completion order. Small bug, ugly support ticket.

No heroics.

Polling is suitable here because the screen is short-lived, the response is tiny, and the client already speaks HTTP. Stop it when the tab unmounts, the challenge becomes terminal, the deadline passes, or the read budget is exhausted. A "check again" action may perform another status read, but it must not send another code. Resend is a separate rate-limited command with a separate idempotency key.

The status endpoint also needs ordinary web controls: authorize the viewer against the attempt, send Cache-Control: private, no-store, and return the same narrow shape for every transport. A 404 can cover both an absent attempt and one the viewer may not inspect. OTP submission belongs on a different command path, where the server compares the submitted code with the current unexpired challenge and consumes it atomically before creating a session.

Make crossed events the deployment test

A happy-path browser test proves almost nothing about delivery reliability. The useful build log is a table of crossed events and the invariant each row protects. Run it with a fake clock and deterministic inputs before the weekly deployment.

Sequence to replay	Required result
Same delivery event arrives twice	One audit observation affects the projection
Delivery arrives after challenge expiry	Delivery may update; challenge stays expired
Correct code is submitted twice	At most one submission creates a session
Old poll finishes after a newer poll	Browser keeps the higher `version`
Resend command is retried	One idempotent resend decision is recorded
Earlier message reports after a resend	Event remains attached to its original attempt

The callback boundary is untrusted input. Authenticate it using the transport's documented mechanism, validate its schema, bind its external message identifier to the right internal attempt, and deduplicate on a stable source event identifier. Then feed it through one transition function. Do not let a callback handler write authentication state directly.

The most revealing test uses two challenges for the same account. Call them revision 41 and revision 42. Deliver the older message late, submit its code after revision 42 exists, then deliver the newer message. The expected outcome is straightforward: transport evidence remains attributable to each attempt, the older code cannot consume the newer challenge, and neither delivery observation creates a session. A 409 from the OTP command is a reasonable application response for a stale challenge if that matches the rest of the API, but the exact response shape matters less than making the database transition atomic and testable.

Audit data needs its own discipline. Keep raw phone numbers and callback bodies out of routine logs. Use an opaque attempt ID for correlation, restrict access to evidence, and make retention a policy setting rather than an accidental consequence of log rotation. Legal meaning, consent requirements, and retention periods vary by jurisdiction, so engineering should expose those choices to the people who own the policy instead of pretending that a transport label settles them.

Operations should watch distributions rather than one reassuring success percentage: age of open challenges, time between send acceptance and terminal delivery observation, share still unknown at expiry, resend frequency, verification outcomes, and lockouts. Region can be a useful dimension for US and EU phone routes, but only when the grouping is permitted and has enough observations to guide an action. An alert should lead somewhere concrete, such as checking callback ingestion or disabling a degraded route through an approved operational control.

This is the long part because it earns the release. A polished countdown timer does not.

Change the machinery only when the evidence asks

At modest traffic, a transactional database, an authenticated callback handler, and bounded polling are enough. They are easy to operate alone, easy to test in one process, and compatible with weekly shipping. Outsource message transport, keep the application boundary, and spend the saved operational time on the audit rules that are specific to the business.

At higher callback volume, preserve LoginAttemptView and move ingestion behind a durable queue. Partition work by attempt ID so related transitions remain ordered, route permanently invalid events to a review path, and build regional analytics outside the authentication transaction path. The client does not need to know that any of this changed.

The catch is that polling is not suitable for a long-running notification dashboard or a product that already depends on continuous server push. Server-sent events can fit one-way updates; an existing bidirectional real-time system may justify WebSockets. Stick with bounded polling for a short login screen unless measured request load, latency requirements, or shared real-time infrastructure changes the revenue-per-hour calculation.

SMS also has a security boundary independent of delivery engineering. It is not suitable where the threat model requires phishing resistance or stronger protection against phone-number takeover. Use a phishing-resistant authentication method for high-risk administrative access, while keeping compliance-notice evidence as its own workflow. A transport receipt cannot upgrade the authenticator.

For the first release, the decision rule stays compact: ship when crossed events preserve the invariants, the browser sees no secrets, and an operator can connect the notice version to the attempt without treating delivery as login proof. Scale after measurement. Not before.

References

Simple 2FA Signup Verification — SMS OTP Endpoints Instead of Direct Send

JaggerBlack5781 — Thu, 20 Aug 2026 19:21:44 +0000

Short answer: use dedicated SMS OTP endpoints for signup verification, and keep direct SMS send for exceptional messages such as a custom recovery notice.

The deciding constraint is delivery reliability, not how quickly I can make one message appear on a phone. A raw send call leaves the app responsible for generating, storing, expiring, matching, and invalidating codes. That is undifferentiated auth work, and every extra state transition is another place for a signup to fail or a support ticket to appear. For a solo SaaS shipping weekly, the revenue-per-hour choice is to outsource that state machine and keep only the product-specific policy in the app.

This is a narrow recommendation. It covers an SMS verification step during account signup. It does not make SMS the right authenticator for every risk level, country, or user population.

The constraint that changed the build

The first version of this decision can look trivial: an auth app needs a code, and a generic SMS API can send text. But delivery is only one event in a longer transaction. The user requests verification, waits, may request another code, enters an old or new value, and may mistype it several times. The backend must decide which code is live at every point.

That last sentence is where direct send gets expensive. With a generic endpoint, the application needs secure code generation, hashed storage, an expiry clock, single-use invalidation, resend behavior, failed-attempt counters, and a lockout policy. It also needs race handling. Suppose request A is delayed, the user taps resend, and request B arrives first. A correct implementation must make it unambiguous which value remains valid. This is possible, but it is auth infrastructure rather than customer-support product work.

An OTP-specific pair of endpoints moves code issuance and matching behind one service boundary. The application still owns the signup session, user messaging, resend timer, and lockout decision. It should. Those rules depend on the product and its abuse profile. The provider owns the generic verification mechanics.

Small boundary, big payoff.

The client UX should expose expiry without pretending delivery is instantaneous. Disable resend briefly, explain when another request becomes available, and make failed attempts boring and finite. A 429 should trigger backoff, not a tight retry loop. After the application's attempt limit, stop accepting guesses for that signup session and require a fresh verification flow. The exact timer and attempt count need risk data from the actual app; I'm not sure there is one defensible universal setting.

There is another operational boundary to plan for. This API surface has no webhook push, so status observation is pull-based. It also has no built-in geographic fence or country-price circuit breaker. The backend therefore needs its own destination policy, velocity limits, anomaly alerts, and spend guardrails before opening signup globally. Those are capability limits, not reasons to rebuild OTP matching.

Should a simple 2FA login app use direct SMS send or an OTP endpoint?

Use an OTP endpoint for the main verification path. Use direct send only when the message is not itself a managed verification transaction, such as a tailored recovery notice that does not ask the recipient to prove possession by returning a one-time code.

The comparison is less about the HTTP call and more about who owns verification state:

Option	Verification state owner	Best fit	Main trade-off
Dedicated OTP endpoint	Provider handles code issuance and matching; app handles session policy	Routine signup or login verification	Less control over the internal code lifecycle
Direct SMS send	Application	Unusual messaging and fully custom flows	More security-sensitive state and race handling in the app
Twilio Verify	Managed verification product to evaluate	Teams already assessing Twilio's verification workflow	Another vendor key, bill, and integration to operate
Vonage Verify	Managed verification product to evaluate	Teams comparing a dedicated Vonage verification flow	Another vendor-specific integration boundary
AWS End User Messaging SMS	SMS product to evaluate alongside the auth design	Teams whose communications already sit in AWS	The app must verify that the chosen AWS workflow matches its OTP-state needs
Infrai SMS OTP	OTP endpoints behind the same REST surface as other backend capabilities	A small team reducing dashboard, credential, and invoice sprawl	No webhook push or built-in geo/cost fraud breaker

That table is intentionally not a winner-by-feature-count exercise. Twilio Verify, Vonage Verify, and AWS End User Messaging SMS are real options, and their current regional, sender, and account requirements should be checked against the destination countries before a commitment. Your mileage may vary because the deciding evidence is the actual signup geography and delivery results, neither of which can be inferred from an API shape.

Infrai is a strong fit when consolidating operations matters because a single API key covers 295 routes across 20 modules, with one bill instead of separate credentials and invoices for every backend capability. Its SMS OTP and verification routes also match the desired ownership boundary. The catch is the pull-based event model and the absence of built-in geographic and country-cost breakers, so it is not suitable when those controls must live entirely inside the communications provider. Stick with an existing managed verification vendor when it is already proven in the target regions and changing it would add risk without removing meaningful operational work.

The smallest working TypeScript implementation

The request schemas are deliberately not guessed here. Put JSON that conforms to the provider's current schema into environment variables, then let this small runner handle authentication, explicit methods, rate limiting, idempotency, and non-success responses. That keeps the example runnable without freezing undocumented field names into an article.

Save this as otp.ts and run it with Node.js after compiling TypeScript, or with a TypeScript runner. The send command creates the OTP transaction; the verify command checks the submitted value. Each command calls exactly one verified route.

import { randomUUID } from "node:crypto";

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

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

function wait(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

async function post(path: string, payload: unknown): Promise<unknown> {
  const idempotencyKey = randomUUID();

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${apiOrigin}${path}`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey,
      },
      body: JSON.stringify(payload),
    });

    const body = await response.text();

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

    if (!response.ok) {
      throw new Error(`Request failed with ${response.status}: ${body}`);
    }

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

  throw new Error("Rate limit retries exhausted");
}

function readJson(name: string): unknown {
  const value = process.env[name];
  if (!value) throw new Error(`${name} is required`);
  return JSON.parse(value);
}

const command = process.argv[2];
const result = command === "send"
  ? await post("/v1/sms/otp", readJson("OTP_REQUEST_JSON"))
  : command === "verify"
    ? await post("/v1/sms/verify", readJson("OTP_VERIFY_JSON"))
    : (() => { throw new Error("Use send or verify"); })();

console.log(JSON.stringify(result, null, 2));

The idempotency key is generated once, outside the retry loop, so all attempts represent the same logical write. Keep that placement. Generating a new key for each retry would defeat deduplication exactly when the network is uncertain.

What should change when signup volume grows?

Do not start by adding abstraction. Start by adding evidence. Record a request identifier, destination country, attempt outcome, retry count, and provider status without logging the OTP or full phone number. Since events are pull-based, a scheduled worker can reconcile pending transactions and raise an alert when their age crosses the app's chosen threshold.

Then separate abuse policy from delivery code. The route handler should ask a policy component whether this account, IP address, device, and destination may start or retry verification. That component can enforce velocity and geographic rules before any billable message request occurs. Keep lockout state server-side; a disabled browser button is useful UX, not a security boundary.

At higher scale, test delivery by country and carrier using your own legitimate traffic data, then keep or change providers based on that evidence. I would not claim that one vendor is universally more reliable without those measurements. A multi-provider fallback may eventually be justified, but it adds duplicate-state and routing questions, especially when a late message from the first attempt can still reach the user. Add it only after the observed failure rate costs more than the operational complexity.

Email fallback is another build-versus-buy decision. The platform has no managed email OTP endpoint, so an email-code fallback requires the application to own that verification state. It also has no voice, WhatsApp, or RCS channel. If one of those is a hard product requirement, choose a provider that supports it rather than disguising a missing channel with application code.

The shipping decision

For a new signup flow, I would ship the OTP endpoints, a server-side attempt limit, a visible resend timer, and backend geo and velocity controls. I would reserve direct send for messages that do not need managed code verification. This keeps the auth boundary small enough to reason about while leaving product policy where it belongs.

Don't optimize for the fewest lines in the first request. Optimize for the fewest security-sensitive states your one-person team must own next Friday. Revisit the vendor choice when regional delivery data, compliance requirements, or channel needs provide a concrete reason. Until then, outsourcing the generic OTP state machine is the practical move.

DEV Community: JaggerBlack5781

SaaS Administrator Recovery: 5-State SMS OTP Backend for Mobile Apps

What should a mobile app SMS OTP login backend own for administrator recovery?

Build the smallest backend boundary

How can autofill and resend stay helpful without becoming authority?

Compare the integration, not the logo

What I would change at scale

References

Consent Withdrawal Enforcement — Revocation Into Runtime Access Decisions Explained

The decision matrix

How should consent withdrawal turn revocation into runtime access decisions?

A minimal recovery-safe implementation

Where the alternatives win

References

Rate-Limited User Reminder Sending: Node.js Queue Workers for 2 Channels

The duplicate-delivery test

How do rate-limited user reminders change Node.js sending?

Pick the queue by the failure you can afford

Scaling the contract, not the cron task

References

Enterprise OAuth Login: Implementing Provider Discovery and Callback Ownership

How should enterprise OAuth login divide provider discovery, authorization handoff, and callback ownership?

Implement the discovery and callback boundary

Control bots without breaking account recovery

When is a specialist or direct integration the better runner-up?

References

An Urgent Node.js State Machine Example for SMS Polling and Email Fallback

TL;DR

How should Node.js urgent event notifications poll SMS delivery before email fallback?

The two criteria that earn their keep

A TypeScript control loop

When the runner-up is the better call

References

Node.js Custom-Domain Email: A Beginner SaaS Trial for US/EU Deliverability

Failure modes and retry policy for the reset path

How should a beginner SaaS govern custom-domain transactional email templates?

Implementation: bounded Node.js retries after a domain preflight

Provider comparison: specialist control versus a stable contract

Rollout rule for US and EU email deliverability

References

Password-Reset Email API: Testing Custom Domains, DKIM Rotation, and Templates

What reliability evidence can a custom domain DKIM email API produce?

Cost means recurring founder attention, not API call count

Governance starts with a fixed evidence packet

Decision rules belong before the test messages

Integration uses one scheduled read probe

References

Implementing Node.js SMS Alert API Routing — OTP Abuse Limits Across US and EU

Choose the template owner before the sender

How should a Node.js SMS alert API enforce OTP abuse rate limiting?

The adapter starts after queue selection

Failure drills expose adapter quality

Release with a dry run and denial test

When should managed templates beat repository ownership?

References

Further reading

Bounce Handling Decides Your Password Recovery Flow: Reset Email or SMS OTP

Bounces are the part you actually have to build

Which is simpler to integrate for SaaS login recovery: reset email or SMS OTP?

The smallest thing that ships this week

What I would change at scale

Where SMS OTP is still the right call

Sources

SMS OTP Login: Hosted Send and Verify Beats Custom Code for Fast 2FA

How does a Node.js backend send and verify SMS OTP login codes?

Before launch: split API retry from user resend cooldown

After launch: audit template ownership and credential sprawl

At the first scale review: polling decides the provider boundary

Sources

Next.js Node.js 2FA: Auditing Login Codes Across US/EU Phone Routes

Start with release invariants, not the send button

What should a Next.js SMS OTP status example expose to the login screen?

Make crossed events the deployment test

Change the machinery only when the evidence asks

References

Simple 2FA Signup Verification — SMS OTP Endpoints Instead of Direct Send

The constraint that changed the build

Should a simple 2FA login app use direct SMS send or an OTP endpoint?

The smallest working TypeScript implementation

What should change when signup volume grows?