React Native Mobile App SMS OTP: Evidence-Governed Backend Access for Logistics Operators

TL;DR: Restore access reliably by making invalid-recipient suppression a reversible, server-owned evidence decision, while treating React Native autofill and resend timers as interface conveniences. Page when eligible administrators stop completing recovery, then use an attempt trace to distinguish bad destination evidence, delayed delivery, throttling, and incorrect codes. The least complex design is one backend policy layer, one normalized delivery adapter, and one auditable suppression ledger.

The page says logistics administrators cannot regain access before a dispatch shift. The on-call sees recovery completions falling, but send requests still being accepted. That mismatch matters: transport acceptance is not receipt, and receipt is not successful account recovery. An alert on API errors alone would stay quiet at exactly the wrong moment.

Work backward from the failed outcome. The trace needs an opaque attempt ID, policy version, send decision, normalized delivery outcome, verification result, and suppression evidence; it must never contain the OTP or a raw phone number. The earlier signal should have been a burn against the recovery SLO, segmented by coarse region and outcome class, rather than a page for every rejected message.

Why did accepted sends end in failed recoveries?

Start with the denominator. Define the recovery SLI as eligible attempts that reach verified status within the server-controlled lifetime divided by eligible attempts started. Keep suppressed, expired, rate-limited, provider-unavailable, and incorrect-code outcomes separate. Combining them produces a tidy graph and a useless incident response: each class has a different owner and remedy.

A depot's shift change can create a legitimate burst. An abusive client can create a similar send rate with almost no successful verifications. Send volume cannot tell those conditions apart, so it is a capacity signal, not a recovery-success signal. Watch sends per completed recovery beside completion rate, and retain the state transitions needed to explain movement in either measure.

The page should fire from sustained SLO-budget consumption, with the exact window and threshold derived from observed traffic and the service's objective. There is no defensible universal requests-per-minute value in the cited material. Inventing one would turn an example into policy without evidence.

Short signal, long investigation.

Suppression is an evidence ledger, not a boolean

An invalid-recipient decision can prevent repeated sends to a destination that cannot receive them, but false suppression locks out a real administrator. Store the reason, source, observation time, policy version, and review status. An explicit permanent-recipient outcome is evidence; a timeout is ambiguous and must not silently become permanent suppression.

This is where governance changes delivery reliability. A bare suppressed=true field cannot answer whether a policy change, a late callback, or an operator created the block. A ledger can. It also supports an alternate recovery route without exposing account existence in the public response.

Keep the outward response equivalent for known, unknown, and suppressed destinations. Internally, use tokenized destination identifiers and keep high-cardinality values out of metric labels. Logs and traces may carry an opaque attempt ID; metrics should carry bounded outcome classes.

The suppression decision should be idempotent and monotonic with respect to evidence: duplicate callbacks must not create duplicate actions, and a late callback must not reopen an expired attempt. Removal is a separate, audited operation. That asymmetry is deliberate because an automatic oscillation between suppressed and active is harder to reason about during an incident than an explicit review.

package recovery

import (
    "context"
    "time"
)

type DeliveryClass string

const (
    DeliveryAccepted         DeliveryClass = "accepted"
    DeliveryTransientFailure DeliveryClass = "transient_failure"
    DeliveryInvalidRecipient DeliveryClass = "invalid_recipient"
    DeliveryUnknown          DeliveryClass = "unknown"
)

type Evidence struct {
    AttemptID      string
    DestinationKey string
    Class          DeliveryClass
    ObservedAt     time.Time
    PolicyVersion  string
}

type SuppressionLedger interface {
    AppendIfAbsent(ctx context.Context, evidence Evidence) (created bool, err error)
}

func RecordDeliveryEvidence(ctx context.Context, ledger SuppressionLedger, evidence Evidence) (bool, error) {
    if evidence.Class != DeliveryInvalidRecipient {
        return false, nil
    }
    return ledger.AppendIfAbsent(ctx, evidence)
}

The function is intentionally narrow. It does not infer permanence from silence, retry the transport, or issue a recovery session. Those belong to separate policy decisions with separate telemetry.

How should backend abuse prevention protect administrator recovery?

The React Native app may request a code, display the server-provided resend time, and offer operating-system autofill. It cannot own the cooldown, code lifetime, guess allowance, or account decision because a modified client can bypass local checks. Client countdowns are display state. Server timestamps are authority. Bind each code to one attempt and one recovery purpose, store only a verifier representation, reject reuse after successful verification, and create the recovery session independently. Autofilled, pasted, and manually typed codes must travel through the same verification path. Do not log any of them. Resend handling then needs an atomic server decision: a two-request race from nearly simultaneous taps must not let both pass the same allowance check, and repeat requests for the same logical action should produce one send reservation. Apply controls across four scopes: the attempt, tokenized destination, tenant or account when known, and cautious network signals. Any single dimension is too easy to evade or too easy to share with innocent users.

The public result still should not reveal whether an account exists. This makes support diagnostics harder unless the opaque attempt ID connects the mobile request to the internal trace, so return that correlation handle wherever doing so does not disclose account state.

Instrument the decision before tuning the alert

Emit one structured event per meaningful decision: attempt started, send reserved, delivery outcome normalized, verification failed, recovery verified, suppression added, suppression removed, or attempt expired. Record elapsed time and policy version. Sample verbose successful detail first if storage pressure demands it; rare terminal outcomes and suppression changes are precisely the records needed during a reliability investigation.

The instrumentation change is small in shape but broad in effect. It lets the on-call ask whether completions fell after accepted sends, whether one outcome mapping began producing suppression evidence, or whether resend pressure rose while unique destination tokens remained flat. None of those questions can be answered from a provider-send counter alone.

Capacity planning belongs in the same review. Estimate peak eligible attempts, repeat-send amplification, callback lag, event retention, and the manual-review queue created by disputed suppressions. A fallback that directs every blocked administrator to support transfers load to people; it does not remove load.

Use a staged policy rollout and compare recovery completion, permanent-recipient evidence, suppression additions, and review demand before expanding it. The point is not a fashionable dashboard. It is a trace that leads from the page to a decision the team can reverse.

Buying transport does not outsource recovery policy

The platform team still owns the recovery SLO, evidence taxonomy, resend rules, and suppression ledger regardless of the delivery boundary. Evaluate a managed SMS service, a cloud communication platform, and a self-operated gateway by the operational boundary they create, not by a feature checklist.

Twilio documents one commercial SMS boundary. Comparable candidates such as Amazon Simple Notification Service and Vonage expose their own boundaries, but a brand count is not analysis and none of them defines the application's recovery semantics. Google publishes email sender guidance, which is useful for understanding that channel policy and recipient hygiene are explicit operational concerns, yet email evidence must not be treated as SMS delivery evidence.

Run an exit drill before choosing a boundary. Can the adapter represent accepted, transient failure, permanent invalid recipient, and unknown without changing account policy? Can evidence be exported for audit? Can callbacks be replayed idempotently? A managed boundary can reduce carrier-facing on-call work, while increasing dependency and migration effort. Self-operation gives more control and assigns the full transport pager to the team. For a small platform group, that staffing consequence deserves more weight than nominal request cost.

This ledger design has a real limitation: it is not suitable as the only recovery path when the organization cannot review disputed suppressions or verify identity through another channel. In that setting, automatic suppression on anything weaker than conclusive invalid-recipient evidence creates an unacceptable lockout risk. The trade-off is operational rather than cosmetic; either staff an alternate verification path, require stronger evidence before suppression, or accept more failed sends while the destination remains eligible.

False positives consume the same error budget

A threshold that is too loose permits abuse, retry amplification, and noisy failure signals. A threshold that is too strict suppresses legitimate administrators and expands the support queue. Both reduce successful recovery, so both belong in the SLO conversation.

Test alert and suppression policies against dispatch-shift bursts, regional delivery degradation, delayed callbacks, and deliberate resend pressure. Record the policy version with every decision, deploy changes gradually, and judge them by completed recoveries plus review load. The correct value comes from production traffic distribution and an explicit objective, not a copied constant.

The operational rule is compact: page on lost recovery outcomes, trace normalized evidence backward, and suppress only when the evidence is conclusive. Everything else is tuning.

Further reading

• Google, "Email sender guidelines": https://support.google.com/a/answer/81126
• Twilio, "SMS documentation": https://www.twilio.com/docs/sms
• Amazon Web Services, "Amazon SNS documentation": https://docs.aws.amazon.com/sns/
• Vonage, "SMS API overview": https://developer.vonage.com/en/messaging/sms/overview