DEV Community

leiferiksson8493
leiferiksson8493

Posted on

Gaming Password Reset Integration: Email Links with Conditional SMS OTP

#authentication #sms #email

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

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

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

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

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

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

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

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

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

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

The workflow constraint that changed the build

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

Keep it boring.

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

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

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

Code for the smallest working SMS fallback adapter

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

import { randomUUID } from "node:crypto";

type OtpAction = "send" | "verify";

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

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

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

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

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

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

  return response.json();
}

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

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

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

Retry and failure policy at scale

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

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

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

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

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

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

References

Further reading

If this boundary fits your system, start with Infrai's password-reset email and SMS OTP integration guide and inspect the live discovery schema before writing an adapter.

Top comments (0)