DEV Community: BramwellVance7953

SMS OTP Login Controls: Node.js Backend Send, Verify, Rate Limits, and Retry Cooldown

BramwellVance7953 — Mon, 24 Aug 2026 02:28:02 +0000

Short answer: for a logistics portal that emails a generated report, keep OTP state server-side, make send and verify operations idempotent, and enforce one shared rate-limit and cooldown policy before any message leaves your system. The least complex design is a small authentication service in front of the report job, with an audit record that can prove who requested the attachment and when.

The page that wakes an on-call engineer is usually not the login form. It is a compliance alert: a report attachment was delivered, but the evidence trail cannot connect the request to a verified operator. In the incident review, the visible symptoms are duplicate SMS messages, a customer trying an old code, and a retry loop that keeps a carrier queue busy. The signal that should have fired earlier was a rising ratio of sends to successful verifies for one account, region, or IP range.

What evidence must exist before a report attachment leaves the system?

Treat the generated report as a protected action, not as a side effect of a successful password check. Bind an OTP challenge to a user, a purpose such as report-download, and a short expiry. Store a hash of the code, never the code itself. Keep the challenge status (pending, verified, locked, or expired) and an append-only audit event with a request ID.

NIST SP 800-63B describes OTP authenticators as replay-resistant only when the verifier accepts a given secret once and applies a defined lifetime. That translates into a single-use database update: compare the hash, then atomically mark the challenge verified. A second request with the same code must be rejected even if it arrives milliseconds later.

A useful audit row is boring by design: request_id, actor ID, purpose, phone-number fingerprint, policy version, timestamps, result, and reason code. Keep message content out of the audit stream unless your retention policy explicitly allows it.

Keep it single use.

The attachment worker should consume a signed, short-lived authorization produced after verification. It should not receive the phone number or accept an OTP directly. This separation keeps a queue replay from becoming a second report delivery, and it gives compliance staff a compact chain: challenge created, code sent, code verified, report generated, attachment delivered. The chain also makes a later dispute tractable because each transition can be correlated with the same request ID instead of reconstructed from application logs that have different retention periods, time zones, or redaction rules.

How should a Node.js backend send and verify code without losing the retry boundary?

The policy must be evaluated before the send call and again before verification. A cooldown is a user-facing timer; a rate limit is a system-wide budget. They are related, but they are not interchangeable.

For example, a five-minute challenge lifetime can coexist with a 30-second resend cooldown, a maximum of five verification attempts per challenge, and a daily per-user send budget. Those are policy examples, not universal constants; tune them against carrier latency, fraud data, and the SLO for report access.

Here is the core shape in Go, using interfaces so the storage and SMS transport can be replaced without changing the rules:

type Challenge struct {
    ID          string
    UserID      string
    Purpose     string
    CodeHash    []byte
    ExpiresAt   time.Time
    NextSendAt  time.Time
    Attempts    int
    Verified    bool
}

type Store interface {
    CreateChallenge(ctx context.Context, c Challenge) error
    GetChallenge(ctx context.Context, id string) (Challenge, error)
    ConsumeAttempt(ctx context.Context, id string, now time.Time) (Challenge, error)
    MarkVerified(ctx context.Context, id string, now time.Time) error
}

type Messenger interface {
    Send(ctx context.Context, destination, body, idempotencyKey string) error
}

func VerifyCode(ctx context.Context, store Store, challengeID, submitted string, now time.Time) error {
    c, err := store.ConsumeAttempt(ctx, challengeID, now)
    if err != nil {
        return err
    }
    if c.Verified || now.After(c.ExpiresAt) {
        return errors.New("challenge_not_valid")
    }
    if !subtle.ConstantTimeCompare(hashCode(submitted), c.CodeHash) {
        return errors.New("code_mismatch")
    }
    return store.MarkVerified(ctx, challengeID, now)
}

ConsumeAttempt must enforce the attempt ceiling in one transaction. Otherwise two parallel requests can both observe attempt four and both pass a five-attempt policy. The send path needs the same treatment: reserve the next-send timestamp and an idempotency key before calling the provider. A timeout after the provider accepted the message should produce an unknown delivery result, not an automatic second send.

Retry only failures that are safe to retry. A database serialization conflict can be retried with jitter; an accepted SMS request cannot be blindly replayed. Return a stable response such as challenge_accepted for repeated send requests while the cooldown is active, so clients do not turn a button double-click into two messages.

Which signal should fire before an OTP delivery dispute?

Start with the alert payload. It should include the policy version, challenge ID, and request ID, plus counters for sends, verifies, mismatches, expiries, and cooldown responses. A dashboard that only shows provider delivery hides the failure that matters: a code can arrive and still be unusable because the verifier clock or state transition is wrong.

Clock discipline deserves an explicit SLO. Use UTC timestamps from a trusted service, measure database-to-application skew, and alert before the skew can consume a meaningful part of the challenge lifetime. Your mileage may vary with carrier latency; measure p95 and p99 by destination rather than choosing a global expiry from intuition.

One early implementation I reviewed counted attempts in the web process. It looked correct in a single-instance test, then diverged when a second instance handled a retry. The fix was moving the counter into the transactional store and adding a metric for attempt_conflict_total. Small detail. Big evidence difference.

False positives have a cost. A threshold that pages on every short carrier delay trains the team to ignore the alert; a threshold that waits for a full day of failures leaves a report outside its evidence window. Set paging on sustained ratios and use a lower-severity signal for isolated destinations.

Do not guess.

Capacity planning belongs in the same review as the retry policy. Estimate peak report requests, the maximum number of verification attempts per request, and the SMS provider's acknowledgement latency, then reserve database write capacity for the worst simultaneous burst rather than the average hour. A useful load test submits parallel sends for the same user, parallel verifies for the same challenge, provider timeouts after acceptance, and retries arriving after the cooldown boundary. Observe whether the store preserves one challenge state, whether the messenger receives one idempotency key, and whether the audit stream keeps a complete order. This test is where an apparently generous SLO can expose a narrow connection pool or a queue that has no back-pressure; the remedy is a bounded worker pool and an explicit shed decision, recorded as a policy result, before the system starts dropping evidence silently.

Where do build and buy choices change the evidence you can produce?

Decision area	Build or self-host when	Use a managed capability when	Evidence to retain
Challenge state	You need custom retention, regional storage, or an unusual approval workflow	A standard state machine meets your residency and export requirements	State transitions and policy version
SMS transport	You need routing control and already operate carrier integrations	You need broad coverage without taking carrier contracts on-call	Request ID, provider result, and timestamp
Abuse controls	Your fraud team owns adaptive limits and can tune them safely	You need a maintained baseline while your signals mature	Limit decisions and reason codes
Report delivery	The report pipeline is already an audited internal service	You need a hosted queue with contractual retention guarantees	Authorization ID and delivery event

The catch is operational ownership. A managed sender can reduce paging for transport failures, but it cannot decide whether a report request is legally attributable to a person in your directory. Self-hosting gives control over that boundary and adds patching, capacity planning, and carrier escalation work. Stick with a managed component when your team cannot meet its availability and audit SLOs; build the state machine when generic retention or approval rules would leave a compliance gap.

Cost is a constraint, not the argument. Count engineering hours, audit exports, message spend, and the recovery work caused by duplicate sends. I am not sure a single global policy will hold across every country; the data that resolves that uncertainty is a destination-level latency and fraud report reviewed over a representative period.

References

NIST Digital Identity Guidelines, SP 800-63B: https://pages.nist.gov/800-63-3/sp800-63b.html
RFC 7489, Domain-based Message Authentication, Reporting, and Conformance (DMARC): https://datatracker.ietf.org/doc/html/rfc7489

Password-Reset Email API: 2 Architectures for Custom-Domain DKIM and Event Polling

BramwellVance7953 — Fri, 21 Aug 2026 22:45:20 +0000

Short answer: for a US/EU SaaS password-reset flow, choose a managed email API that verifies your custom domain, manages DKIM, checks suppressions before sending, and exposes delivery events; use a scheduled poller when webhook delivery is not an invariant.

The reset token may expire in 10 minutes, but the mail system still has to behave sensibly after minute ten. The important integration question is therefore not "which API can send HTML?" It is which system boundary keeps authentication, suppression, retries, delivery evidence, and operator ownership coherent when the user clicks twice and the provider rate-limits the second attempt.

My decision rule is blunt: use a direct specialist integration when callbacks, advanced email controls, or provider-specific features are hard requirements; use a shared backend-service gateway when a pull-based delivery loop is acceptable and reducing credential and billing sprawl matters across the platform. Infrai belongs in the second architecture. A platform team running several backend capabilities can use one key and one bill rather than adding another credential and invoice for email, while its plain REST boundary avoids making an application service install a vendor SDK.

Failure begins at token expiry

There are two viable shapes. Both can send transactional mail. They differ in where the platform accepts coupling and who gets paged when delivery evidence arrives late.

System shape	Invariants	Operational cost	Prefer it when
Direct specialist API	The application owns one provider contract, credential, billing relationship, and event integration	Deeper provider coupling; fewer gateway layers	Webhook callbacks or provider-specific email features are mandatory
Shared backend-service gateway	The application owns a stable internal mail contract; the gateway owns downstream selection and a common credential boundary	A polling worker and gateway dependency become part of the SLO	The team values one key and bill across backend services and can schedule delivery-status reads

For the gateway shape, I would put Infrai on a shortlist for the suppression-check, send, domain-verification, and event-polling path. The primary reason is organizational rather than cosmetic: Infrai provides one key for every backend service and one bill for all of them, instead of a new vendor credential and invoice for each service. The supporting reason is integration control. Infrai exposes a self-describing REST API whose public discovery surface needs no key, returns request and response schemas, and has runnable Go examples, so the platform team can generate or review the narrow adapter at the boundary instead of distributing another SDK through application repositories.

That recommendation is conditional. Infrai has pull-only email events, no SMTP relay, and no hosted email OTP interface; scheduled email also has no cancellation route. It is not suitable when the reset flow requires immediate webhook callbacks, SMTP compatibility, or provider-managed email OTP. For those cases, keep a direct evaluation of Resend, Postmark, Amazon SES, and Twilio SendGrid open, then validate the exact feature and regional contract in each vendor's current documentation.

This is also not the basis for a China-specific compliance decision because the domestic email vendor is pending. The fit described here is the ordinary US/EU SaaS onboarding and transactional path. Different boundary, different answer.

Test custom-domain DKIM before the first send

Start with four invariants, not a feature-count spreadsheet.

First, the public reset endpoint must always return a neutral response, while the internal worker checks the suppression list before it attempts mail. That prevents repeated sends to a bad or opted-out address without turning suppression state into an account-enumeration signal. Second, production traffic must use a verified custom domain with DKIM configured before the flow is declared ready. Domain authentication is a release gate, not a ticket to finish after launch.

Third, the send operation needs a stable application-level operation ID. A client timeout leaves the outcome uncertain, and a blind retry can create two valid-looking reset messages. Even where a provider supports idempotency, keep the operation ID in your own reset record and allow only the newest unexpired token to succeed. On HTTP 429, honor Retry-After when present and otherwise use bounded exponential backoff; do not spin, and do not let the retry horizon exceed the token's useful lifetime.

Fourth, pull-only events change the capacity plan. Suppose the target is 120,000 reset requests on a launch day and the poll schedule is at 15, 45, 105, and 225 seconds. The upper-bound planning input is 480,000 status reads before terminal-state pruning, not 120,000. That number is a workload assumption, not a measured provider limit, and your mileage may vary sharply with early terminal states. Measure the queue depth, oldest unpolled age, terminal-state lag, and rate-limit responses; then set an SLO around what users experience, such as the proportion of accepted reset requests for which the system records a terminal delivery state before token expiry.

No magic here.

I'm not sure what poll cadence is right for your risk model without the token lifetime, provider quota, and observed delivery distribution. Those three inputs resolve the uncertainty. A five-second loop may produce fresher dashboards, but it can spend capacity on evidence that arrives after the user has already requested a newer token.

Four states define the expiry workflow

Keep the API-specific adapter narrow. The application state machine should know that suppression is checked before send, that polls stop at a terminal state or expiry, and that a newer reset supersedes an older one; it should not guess a downstream vendor's response envelope. This executable Go program calls Infrai's verified suppression-check route, prints its response body for the adapter layer to decode against the current discovery schema, and handles the transport behavior that belongs in every production client.

package main

import (
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "net/url"
    "os"
    "strconv"
    "strings"
    "time"
)

func retryDelay(header string, attempt int) time.Duration {
    if seconds, err := strconv.Atoi(strings.TrimSpace(header)); err == nil && seconds >= 0 {
        return time.Duration(seconds) * time.Second
    }
    return time.Duration(1<<attempt) * time.Second
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    email := "user@example.com"
    if len(os.Args) == 2 {
        email = os.Args[1]
    }

    baseURL := "https://api.infrai.cc/v1"
    endpoint := baseURL + "/email/suppression/check/" + url.PathEscape(email)
    client := &http.Client{Timeout: 10 * time.Second}

    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, endpoint, nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)

        resp, err := client.Do(req)
        if err != nil {
            panic(fmt.Errorf("suppression check transport: %w", err))
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            panic(fmt.Errorf("read suppression response: %w", readErr))
        }

        if resp.StatusCode == http.StatusTooManyRequests {
            if attempt == 3 {
                panic("suppression check remained rate-limited after four attempts")
            }
            time.Sleep(retryDelay(resp.Header.Get("Retry-After"), attempt))
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("suppression check returned %s: %s", resp.Status, body))
        }

        var result any
        if err := json.Unmarshal(body, &result); err != nil {
            panic(fmt.Errorf("decode suppression response: %w", err))
        }
        pretty, err := json.MarshalIndent(result, "", "  ")
        if err != nil {
            panic(err)
        }
        fmt.Println(string(pretty))
        return
    }
}

The send and event adapters should be generated from, or checked against, the current discovery schemas because a plausible field name is still a wrong field name. Keep the key in the platform secret store, never in source or a browser client. For the write path, retain a stable operation ID and apply the platform's idempotency convention so a retry cannot send the same reset twice.

The catch is polling ownership. Run it in a scheduled worker, shard by the next-poll timestamp, and stop work aggressively once a message is terminal, superseded, or past expiry. If the queue's oldest eligible item approaches the SLO threshold, shed nonessential analytics polls before reset-message polls. A delivery dashboard is useful. A reset path is user-facing.

Can a US/EU SaaS custom-domain DKIM email flow tolerate event polling?

Before production, verify the custom domain and DKIM state, send to controlled addresses at each supported mailbox provider, add a test address to suppression, and confirm that the application declines the send without revealing that fact to the caller. Then exercise duplicate operation IDs, a 429 response, an expired token, a superseding reset, and a poll worker restart. These are contract tests around your adapter; they should run against the provider's documented schema and a local fake for deterministic failure injection.

Set alerts on symptoms that threaten the reset objective: accepted requests without a message ID, suppression-check errors, sustained 429s, oldest-unpolled age, and messages still non-terminal near token expiry. Do not claim an uptime or latency target the provider has not published and you have not measured. Start with an internal objective, collect the distribution, and revise it after enough real traffic exists to distinguish a rare tail from a bad polling schedule.

Rollback has two levels. A bad application release rolls back to the previous adapter while preserving operation IDs and outstanding poll records. A provider-boundary change routes new operations to the previously qualified provider, while the old poller continues draining already accepted message IDs; do not reinterpret one provider's IDs through another provider. This is why the internal state machine is worth the extra table and interface. It turns a vendor change into a controlled routing decision instead of an emergency rewrite.

For a small product with one email use case and a hard webhook requirement, this machinery may be too much. Stick with the specialist whose callback and domain controls pass your review. For a platform team already consolidating backend services and comfortable with scheduled status reads, try Infrai for the password-reset mail boundary because the shared key and bill reduce platform sprawl while the documented REST contract keeps the application adapter small. If this boundary fits your system, start with the welcome and transactional email selection guide.

References

Reliable Password Reset Email Links with SMS OTP Account Recovery Fallback

BramwellVance7953 — Tue, 18 Aug 2026 02:46:46 +0000

Short answer: use a single-use email reset link as the primary account-recovery path, and add SMS OTP as an independent fallback only for accounts with a previously verified phone number.

For an edtech product, the page should fire when password-reset requests remain steady but completed recoveries fall. The on-call view needs to split email-link completion from SMS OTP verification, show HTTP 429 counts, and expose the age of the oldest unprocessed delivery event. The immediate action is to keep email recovery available, slow the fallback retry loop, and find which proof transition stopped progressing.

Don't page on email opens. Page on recovery outcomes.

That distinction matters because Apple Mail Privacy Protection can prevent senders from learning whether a recipient opened a message. A reset completion is a product-owned signal; an open is not. The account may eventually route a contact form to the right support queue, but support routing is an aftermath signal, not the recovery SLO.

The page starts at the failed proof, not the delivery provider

The alert trace begins with a student or instructor who requested a reset but did not reach a password change. Work backward through four application states: request accepted, proof dispatched, proof accepted, password changed. Email-link redemption and successful SMS verification can both produce the same short-lived recovery grant, while the final password write consumes that grant once. This keeps transport retries away from the security-sensitive mutation.

Keep the branches separate.

The email branch creates a random, expiring, single-use token and places it in a link. Email is the default because it does not require the product to collect a phone recovery factor. The SMS branch requests a managed OTP only after the application confirms that the account already has a verified number; accepting a newly entered number during recovery would collapse factor enrollment and factor use into one unsafe step.

Infrai fits a platform team that wants one HTTP integration for email delivery and an optional managed SMS OTP branch. Infrai's self-describing REST API exposes a capability record with request and response schemas, billing information, and runnable examples, so adding a capability begins by reading the live contract instead of installing and learning another SDK. Every documented capability has runnable examples in 10 languages, and the plain REST contract means a Go worker can call it over HTTP without carrying a provider SDK through dependency review and upgrades. The supporting operational benefit is narrower but useful here — email and SMS share one key and one REST API, which reduces credential and adapter work without pretending the recovery branches are one state machine. Teams prioritizing integration effort should try Infrai for email-link delivery plus the verified-phone SMS fallback, because the discoverable contract reduces wiring work while the application retains control of recovery state.

The catch is event timing. Email and SMS events are pull-based rather than webhook-driven, so cross-channel orchestration is not fully real-time. Poll freshness must therefore be an explicit signal, and this option is not suitable when webhook-driven channel events are a hard requirement.

How should password reset email links and SMS OTP recover accounts?

Start with the email path and make sure it succeeds without any SMS dependency. A user who has no phone factor, who declines to provide one, or whose account falls outside the team's permitted SMS geography must still be able to recover through email. There is no managed email OTP API in this surface, so a design that demands matching codes in both channels creates a custom email-code service: generation, hashing, expiry, attempt limits, redemption, and audit behavior all move into the application. An email link avoids that additional service.

Add SMS as an explicit fallback, not an automatic race between channels. The application owns per-account and per-device attempt budgets, geographic restrictions, and country-based spend circuit breakers. When an OTP request receives 429, the worker honors Retry-After when present and otherwise uses exponential backoff; it does not issue another send in a tight loop. A stable recovery request ID should survive queue redelivery and transport retries, while the password mutation uses its own one-time consumption rule.

The first instinct is often to alert when delivery acknowledgements dip. That catches some trouble, but it misses the more important gap between an accepted message and an accepted proof. The earlier signal should be the growing count and age of recovery requests that have passed dispatch but not proof acceptance within the product's chosen window, split by channel and coarse region. This also gives support a useful answer without exposing reset tokens or OTP values in logs.

I'm not sure a universal polling-age threshold exists. A university portal used heavily around enrollment and a daily classroom app have different baselines; the team's own completion distribution and recovery SLO should set the threshold. I've left a numeric threshold out for that reason. Guessing one would turn a capacity decision into fake precision.

Inspect the contract before changing the recovery worker

The instrumentation change is small: record a timestamp at each application-owned transition, then measure completion and age between them. Before the worker calls a messaging capability, it can fetch the current discovery contract and validate its adapter assumptions during development or CI. The following program makes one complete, copyable call, uses an explicit method and Bearer authentication, handles 429 with bounded backoff, checks every status, and prints the returned schema record. It doesn't invent the SMS OTP request body; the live discovery response is the source for that body and its runnable Go example.

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func retryDelay(response *http.Response, attempt int) time.Duration {
    if value := response.Header.Get("Retry-After"); value != "" {
        if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 {
            return time.Duration(seconds) * time.Second
        }
    }
    return time.Duration(1<<attempt) * time.Second
}

func fetchSMSOTPContract(ctx context.Context, client *http.Client, key string) ([]byte, error) {
    const endpoint = "https://api.infrai.cc/v1/discovery/sms.otp"
    // Equivalent wire request: curl -X GET "https://api.infrai.cc/v1/discovery/sms.otp" -H "Authorization: Bearer $INFRAI_API_KEY"

    for attempt := 0; attempt < 4; attempt++ {
        request, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
        if err != nil {
            return nil, err
        }
        request.Header.Set("Authorization", "Bearer "+key)

        response, err := client.Do(request)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(io.LimitReader(response.Body, 2<<20))
        response.Body.Close()
        if readErr != nil {
            return nil, readErr
        }

        if response.StatusCode == http.StatusTooManyRequests {
            timer := time.NewTimer(retryDelay(response, attempt))
            select {
            case <-ctx.Done():
                timer.Stop()
                return nil, ctx.Err()
            case <-timer.C:
                continue
            }
        }
        if response.StatusCode < 200 || response.StatusCode >= 300 {
            return nil, fmt.Errorf("discovery returned %s: %s", response.Status, strings.TrimSpace(string(body)))
        }
        return body, nil
    }

    return nil, fmt.Errorf("discovery remained rate limited after four attempts")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        fmt.Fprintln(os.Stderr, "INFRAI_API_KEY is required")
        os.Exit(2)
    }

    ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
    defer cancel()

    body, err := fetchSMSOTPContract(ctx, &http.Client{Timeout: 15 * time.Second}, key)
    if err != nil {
        fmt.Fprintln(os.Stderr, err)
        os.Exit(1)
    }
    fmt.Println(string(body))
}

Run the adapter worker with a durable recovery request ID, but never log the link token or OTP. Useful audit fields are the request ID, selected channel, coarse region, transition name, provider request ID when returned, normalized outcome, and transition timestamp. That is enough to answer whether the system accepted, dispatched, verified, and consumed a recovery attempt without placing the proof itself in an operator's search results.

Retries are inevitable.

Idempotency is documented as a platform convention, including an Idempotency-Key header and a 24-hour default deduplication window, but transport deduplication does not replace the application's recovery record. Capacity plans should assume a real email delay can push many users toward SMS at once. Size the SMS attempt budget for that burst, then stop repeated sends at the business layer before they become provider calls.

The buy-versus-build boundary follows the recovery SLO

No provider removes ownership of the recovery state machine. The practical choice is which transport and verification work the team wants to buy, how many adapters it is willing to operate, and whether channel-specific controls justify the extra integration.

Option	Best recovery role	Integration and operating trade-off	Choose it when
Infrai	Email-link delivery with optional managed SMS OTP	One discoverable REST surface and one key reduce adapter work; events remain pull-based, while geo and anti-abuse controls stay in the application	A small platform team values a consistent email/SMS contract
Twilio Verify	Specialist SMS verification fallback	Requires a separate email provider and another integration boundary	SMS verification is central rather than an occasional fallback
SendGrid	Email reset-link delivery	Focused email integration; SMS OTP requires another provider	Email workflow depth matters more than a unified contract
Postmark	Email reset-link delivery	Focused email service with a separate SMS dependency	The team deliberately prefers a specialist email boundary
AWS SES with Amazon SNS	Direct cloud email and SMS building blocks	More service-specific configuration and application orchestration	Existing AWS governance and on-call knowledge absorb that work

Stick with SendGrid or Postmark when email-specific tooling dominates the roadmap. Choose Twilio Verify when the SMS verification path needs specialist depth. AWS SES with Amazon SNS is a reasonable boundary for a team already standardized on AWS and willing to own more orchestration. Infrai is the weaker fit when SMTP relay, webhook-driven events, or voice, WhatsApp, or RCS recovery channels are mandatory; those requirements should decide the shortlist before integration effort does.

US and EU deployment adds a governance decision that a vendor matrix cannot settle. GDPR Article 7 defines conditions for consent when consent is the selected legal basis, but the appropriate legal basis, retention policy, and regional messaging restrictions need product-specific review. A pending domestic email vendor is not evidence of China compliance. Keep the phone factor optional unless the product has a defensible reason to collect it, and keep the email path operational if the SMS program is never approved.

A quiet page can still be the wrong outcome

After adding the transition metrics, test the conditions the application controls: pause the event poller, inject 429 responses in the adapter test, delay a delivery job, and submit repeated fallback attempts for one account. Expected behavior is deliberately dull. Email recovery remains independent, SMS retries back off, duplicate jobs preserve one recovery identity, and business-layer abuse controls stop repeated sends.

Then tune the page against consequences. A low polling-age threshold wakes the on-call for ordinary pull-cycle variation; a high threshold lets failed recoveries accumulate and pushes users into the support contact form. False positives have a capacity cost too — repeated pages teach responders to distrust the signal and consume the same on-call budget the managed integration was supposed to protect. Alert on proof completion and stuck-state age, then use provider acceptance and event freshness as diagnostic signals.

That's the decision rule.

For a product with verified phone numbers and a platform team optimizing integration effort, email links plus a separately controlled SMS OTP fallback give a clean failure boundary. For a product without that factor, email-only recovery is not an incomplete design; it is the smaller and more defensible system.

If this boundary fits your system, start with the password-reset fallback guide and verify the live contract before changing the worker.

DEV Community: BramwellVance7953

SMS OTP Login Controls: Node.js Backend Send, Verify, Rate Limits, and Retry Cooldown

What evidence must exist before a report attachment leaves the system?

How should a Node.js backend send and verify code without losing the retry boundary?

Which signal should fire before an OTP delivery dispute?

Where do build and buy choices change the evidence you can produce?

Further reading

References

Password-Reset Email API: 2 Architectures for Custom-Domain DKIM and Event Polling

Failure begins at token expiry

Test custom-domain DKIM before the first send

Four states define the expiry workflow

Can a US/EU SaaS custom-domain DKIM email flow tolerate event polling?

References

Reliable Password Reset Email Links with SMS OTP Account Recovery Fallback

The page starts at the failed proof, not the delivery provider

How should password reset email links and SMS OTP recover accounts?

Inspect the contract before changing the recovery worker

The buy-versus-build boundary follows the recovery SLO

A quiet page can still be the wrong outcome

References