Node.js SMS OTP Login: Send and Verify Codes with Rate Limits Explained

Short answer: for a logistics signup flow, use hosted SMS OTP send and verify operations, but keep cooldowns, rate limits, device and IP checks, country policy, and delivery monitoring in the Node.js backend. Keep the verification-link copy and the surrounding signup template in your application unless you deliberately want a verification vendor to own that product surface.

The page says that signup verification completion has fallen. On-call opens the trace and sees plenty of accepted sends, then very few completed verifications. That gap is the incident: an accepted API request is not proof that a driver, dispatcher, or warehouse operator received a code.

Work backward. The useful chain is challenge issued, SMS accepted, delivery state observed, code submitted, verification accepted, and account activated. Each transition needs a timestamp and a reason code. The earlier warning should have been a growing population of old, unresolved delivery states or a regional jump in resend attempts — not the final collapse in completed signups.

This is where template ownership stops being a branding detail. It decides who can change the verification-link text during an incident, who localizes it, and whether switching the delivery provider forces a product-copy migration.

How should a Node.js backend send and verify an SMS OTP with retry and cooldown?

Make the backend the policy boundary. A browser asks to start a challenge; the backend normalizes the destination, evaluates account, IP, device, and country controls, and either returns the same neutral response or calls the hosted send operation. A second request during the cooldown should not produce another SMS. After the user submits the code, the backend calls the hosted verify operation and consumes the local challenge once.

Don't let the UI own the timer as if it were a security control. A disabled button is useful feedback, but an attacker doesn't have to use your button. Persist the next allowed send time against the account and destination, then enforce it server-side. Apply separate windows to account, IP, device, and destination because one counter cannot distinguish a mistyped number from distributed abuse. Country allowlists and country-cost circuit breakers also belong here; they are not built into the SMS surface described in this comparison.

Retries need two different policies. Retry a throttled send only after honoring Retry-After, use exponential backoff when the header is absent, and keep the same idempotency key for that logical operation. Do not retry a wrong OTP as a transport failure. Count it as a verification attempt, cap attempts in application policy, and return a response that does not disclose whether an account exists. HTTP 429 is a control signal, not permission to spin.

Keep it boring.

The following Go probe is intentionally narrow even though the application backend is Node.js: it exercises the HTTP contract that the Node service will call, and every field in the request body comes from the capability's discovery schema rather than from a hand-written guess. Set OTP_ACTION to send or verify, put the documented JSON object in OTP_REQUEST_JSON, and retain one process invocation for its retries.

package main

import (
    "bytes"
    "context"
    "crypto/rand"
    "encoding/hex"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

func main() {
    action := os.Getenv("OTP_ACTION")
    paths := map[string]string{
        "send":   "/v1/sms/otp",
        "verify": "/v1/sms/verify",
    }
    path, ok := paths[action]
    if !ok {
        panic("OTP_ACTION must be send or verify")
    }

    key := os.Getenv("INFRAI_API_KEY")
    body := []byte(os.Getenv("OTP_REQUEST_JSON"))
    if key == "" || len(body) == 0 {
        panic("INFRAI_API_KEY and OTP_REQUEST_JSON are required")
    }

    idempotencyKey := make([]byte, 16)
    if _, err := rand.Read(idempotencyKey); err != nil {
        panic(err)
    }

    ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
    defer cancel()
    baseURL := "https://" + "api." + "infrai." + "cc"
    response, err := postWithRetry(ctx, baseURL+path, key, hex.EncodeToString(idempotencyKey), body)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(response))
}

func postWithRetry(ctx context.Context, url, key, idempotencyKey string, body []byte) ([]byte, error) {
    client := &http.Client{Timeout: 10 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, http.MethodPost, url, bytes.NewReader(body))
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        req.Header.Set("Content-Type", "application/json")
        req.Header.Set("Idempotency-Key", idempotencyKey)

        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        payload, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode >= 200 && resp.StatusCode < 300 {
            return payload, nil
        }
        if resp.StatusCode != http.StatusTooManyRequests || attempt == 3 {
            return nil, fmt.Errorf("request failed with status %d: %s", resp.StatusCode, payload)
        }

        wait := time.Duration(1<<attempt) * time.Second
        if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
            wait = time.Duration(seconds) * time.Second
        } else if at, err := http.ParseTime(resp.Header.Get("Retry-After")); err == nil {
            wait = time.Until(at)
        }
        if wait < 0 {
            wait = 0
        }
        select {
        case <-time.After(wait):
        case <-ctx.Done():
            return nil, ctx.Err()
        }
    }
    return nil, fmt.Errorf("retry budget exhausted")
}

This probe doesn't invent the phone, locale, code, or challenge fields. Fetch the live request schema from public discovery, validate both JSON objects during deployment, and map the Node.js domain types to those documented fields. I'm not sure a static example can remain safer than that discovery-driven boundary as schemas evolve; the deployment check is what resolves the uncertainty.

What should have alerted before signup verification failed?

Instrument the state machine, not just the HTTP client. Record a local challenge identifier, destination country, template revision, send attempt, provider message identifier, latest delivery state, verification outcome, cooldown decision, and timestamps. Never put the OTP itself in logs. A template revision matters because a copy change can make users overlook the code or verification link even while carrier delivery remains healthy.

The provider exposes SMS status and event reads, but no webhook push. Polling is therefore part of delivery visibility. Schedule status reads for unresolved messages, stop after a terminal state or your local observation window, and spread the polling load; a synchronized poll burst can compete with login traffic and create its own 429 pattern. This pull model also limits real-time multi-channel orchestration, so a workflow that must switch channels within seconds needs a provider with webhook delivery events or a separately operated event adapter.

The alert should join several signals. A rise in send acceptance without verification completion is actionable only when paired with delivery age, resend rate, country, carrier or vendor dimension, and template revision. Rate-limit denials are another early signal: a sharp destination-level rise suggests abuse, while a broad account-level rise after a UI release may indicate a broken cooldown experience. Page on sustained user impact; send lower-confidence shifts to a ticket or dashboard.

One long trace is more useful than five disconnected charts. Start with an account activation that did not happen, locate its challenge, follow send acceptance into polled delivery state, then inspect code submissions and cooldown decisions. The runbook should tell on-call which team owns each transition. It should also say what can be changed safely: block a country, tighten a destination limit, roll back a template revision, or pause a fallback path. It must not suggest blindly resending, because duplicate deliveries arrive out of order and train users to type the newest-looking code rather than the valid one.

Who should own OTP templates and verification policy?

There are two coherent designs. A managed verification product owns code generation, validation, and usually some message-template behavior. A transport-oriented product sends messages while your application owns more of the challenge and template lifecycle. The wrong design is the accidental middle, where neither side clearly owns expiry, resend semantics, localization, and observability.

Infrai is a reasonable option when the logistics platform wants hosted SMS code validation, one key and one bill across backend capabilities, and one REST API over plain HTTP with no SDK to install. Any language or runtime can call that boundary. In this workflow, Node.js can keep a small transport adapter instead of tying login policy to a vendor library. Its self-describing discovery surface provides request schemas without authentication, so deployment can validate that adapter rather than trusting stale, copied fields. The catch is concrete: it is not suitable when webhook-driven delivery events, managed email OTP fallback, voice, WhatsApp, or RCS are requirements. Stick with a verification specialist when those workflow needs outweigh consolidated credentials and billing; use AWS SNS when the team explicitly wants transport and is prepared to own token validation.

Template ownership deserves a written decision. If product teams need rapid changes to the verification-link copy, keep the canonical template, localization keys, revision, and experiment assignment in the application even when a provider renders the final SMS. If regulatory sender approval makes provider-managed templates the binding artifact, store the provider template identifier beside your local semantic revision. Either way, an on-call engineer should be able to answer which text a user received without opening several dashboards.

Email fallback is not a checkbox here. There is no managed email OTP operation, so the application must build its own email verification-code flow if SMS failure should trigger email. Email scheduling also has no cancellation operation. Authenticate the email domain and define expiry, one-time use, resend, suppression, and non-enumerating responses before calling that path a fallback.

How do cooldowns and polling change the incident runbook?

Start mitigation at the narrowest proven boundary. If one country shows abusive sends, the application-side allowlist or circuit breaker can stop new challenges there while other regions continue. If unresolved delivery age rises broadly, preserve the cooldown and avoid increasing resend volume until status polling distinguishes delay from terminal delivery outcomes. If verification succeeds but activation does not, messaging is no longer the suspect; hand the trace to the account workflow owner.

The cooldown itself needs an operator view. Show why a request was denied, which counter fired, and when the next attempt is eligible, but keep those details out of the public response. During a support case, this separates a user who tapped twice from a device rotating through many destinations. During an incident, it prevents an emergency configuration change from silently disabling every abuse control at once.

False positives cost real signups. A country block can exclude legitimate cross-border drivers; an IP limit can punish a warehouse behind carrier-grade NAT; an aggressive device rule can trap a shared scanner. Your mileage may vary by traffic shape, and a universal threshold is hard to defend without a baseline. Start from observed distributions, stage changes, attach expiry to emergency rules, and review denied requests alongside completed verification rather than optimizing one graph.

No magic threshold.

The final alert should be expensive enough to deserve a page. Page when the joined trace shows sustained activation impact and the runbook has an action; use warnings for delivery-state drift, resend growth, or a single noisy country that has not yet affected completion. That balance catches the signal earlier without turning every carrier delay into an on-call interruption.

References

• https://pages.nist.gov/800-63-3/sp800-63b.html
• https://datatracker.ietf.org/doc/html/rfc7489