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

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:

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.

References

• https://developer.mozilla.org/en-US/docs/Web/API/WebOTP_API
• https://www.twilio.com/docs/verify/api
• https://developer.vonage.com/en/verify/overview
• https://docs.aws.amazon.com/sms-voice/latest/userguide/what-is-service.html
• https://datatracker.ietf.org/doc/html/rfc7208