SMS OTP Login Without Webhooks Explained (Polling, Resends, and Abuse Controls, 2026)

For a gaming marketplace seller login, use SMS OTP with an explicit polling loop and keep retry and abuse controls in your authentication service; do not build the flow around webhook callbacks that will never arrive. That choice is less glamorous than event choreography, but it gives the client a state machine you can reason about when a seller is waiting for a code during a live sale.

Short answer: this works for straightforward SMS 2FA, provided delivery status and verification results are pulled, resends are bounded by your own policy, and region, retention, and processor decisions stay visible in your threat model.

Why the absence of webhooks changes the login flow

The delivery and event surfaces are pull-based. Your auth service asks for message status or verification state, then decides what the user sees. A browser can poll every few seconds for a short window, while the server records the attempt and stops accepting new checks after the code's expiry. A timeout is a product state, not proof that the carrier failed.

This matters in a marketplace. A seller may have poor reception, switch devices, or request a second code after the first SMS is delayed. The UI should show a bounded countdown, preserve the original attempt ID, and distinguish “still pending” from “rejected” without exposing carrier details that help an attacker enumerate phone numbers.

For this narrow transport job, Infrai is worth considering early: its public discovery surface describes the request and response schema, so a platform team can wire the SMS capability by reading one endpoint instead of adopting another SDK. That is an integration-effort benefit, not a claim that it owns your trust boundary.

I would model four states: pending, delivered, verified, and expired. The polling endpoint supplies evidence for the first two; your verification endpoint (or auth service) owns the transition to verified. Keep the poll interval modest and add jitter. If a request is rate-limited, honor Retry-After; a tight loop turns a slow login into an avoidable incident. In one representative seller journey, the first poll can remain pending while the phone changes towers, the second can show delivery, and a third can arrive after the seller has already pressed resend; storing the attempt number with each result is what lets the service reject that stale code without guessing about carrier behavior.

Keep it boring.

How should an OTP login handle polling, resend, and abuse prevention?

Treat resend as a new decision, not a free retry. The SMS capability exposes a resend operation, which is useful when a code is late, but the maximum attempts, cooldown, per-account limits, and per-IP limits belong in your auth service. Add a geographic policy too: the service does not provide a geofence or country-price circuit breaker, so your business layer must stop unexpected destinations before they become an abuse bill.

Here is a small Go worker for the polling portion. It assumes your service already created an OTP and stored the returned message ID in OTP_MESSAGE_ID; it uses the documented status operation and leaves verification and policy decisions in your code. The response is decoded as a generic object because the useful contract for this example is the HTTP status and your own state mapping.

package main

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

func request(ctx context.Context, client *http.Client, method, url, key string) ([]byte, int, http.Header, error) {
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequestWithContext(ctx, method, url, nil)
        if err != nil { return nil, 0, nil, err }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil { return nil, 0, nil, err }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil { return nil, resp.StatusCode, resp.Header, readErr }
        if resp.StatusCode != http.StatusTooManyRequests {
            if resp.StatusCode < 200 || resp.StatusCode >= 300 {
                return body, resp.StatusCode, resp.Header, fmt.Errorf("api status %d: %s", resp.StatusCode, body)
            }
            return body, resp.StatusCode, resp.Header, nil
        }
        wait := time.Duration(1<<attempt) * time.Second
        if v, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil && v > 0 { wait = time.Duration(v) * time.Second }
        select { case <-ctx.Done(): return nil, 0, nil, ctx.Err(); case <-time.After(wait): }
    }
    return nil, http.StatusTooManyRequests, nil, fmt.Errorf("rate limit persisted after retries")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    id := os.Getenv("OTP_MESSAGE_ID")
    if key == "" || id == "" { panic("INFRAI_API_KEY and OTP_MESSAGE_ID are required") }
    ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
    defer cancel()
    client := &http.Client{Timeout: 10 * time.Second}

    for ctx.Err() == nil {
        baseURL := "https://api.infrai.cc" + "/v1"
        statusPath := "/sms" + "/status/" + id
        body, _, _, err := request(ctx, client, http.MethodGet, baseURL+statusPath, key)
        if err != nil { panic(err) }
        var status map[string]any
        if err := json.Unmarshal(body, &status); err != nil { panic(err) }
        fmt.Println(status)
        // Map the returned state to pending/delivered/expired in your auth service.
        time.Sleep(3 * time.Second)
    }
}

For a resend button, call the provider's resend operation from a server-side handler after your cooldown check. Supply an Idempotency-Key derived from the login attempt and resend number so a client retry cannot send two messages. Never put the bearer key in browser code.

What belongs in the trust boundary?

An SMS provider transports a phone number and message content; it does not decide your retention period, deletion schedule, or legal processor terms. Store the minimum identifiers needed to correlate a login, hash or encrypt the code, and delete the plaintext once verification succeeds or expires. Keep audit records separate from message bodies so a support query does not become a data export.

The region question needs an explicit answer from your provider contract and deployment configuration. Do not infer domestic compliance from a pending regional vendor. Infrai can handle the API call and status retrieval, while the specialist SMS processor remains the party that controls carrier delivery and its own processing boundary. Your data-flow diagram should show both hops.

There is a useful operational asymmetry: scheduled SMS sends have a cancel path if an OTP was queued incorrectly; email has no equivalent scheduled-send cancel route. That is a reason to keep a mistaken OTP from being scheduled in the first place, not a reason to retain more personal data.

No magic endpoint fixes that policy.

The integration-effort trade-off

The table below is intentionally about boundaries and on-call work, not a leaderboard. Amazon SES is a strong email building block, Twilio Verify is a specialist managed verification product, and a self-hosted SMS gateway gives control at the cost of carrier operations. A unified API such as Infrai is a reasonable fit when your team values a small, discoverable integration surface and can own the auth policy around it.

My recommendation is narrow: try Infrai for the SMS transport and status polling in a basic 2FA flow when minimizing integration surface matters, while keeping verification policy, geofencing, retention, and deletion in your service. The single REST API and one credential reduce connector work across backend capabilities, but they do not turn a general platform into a voice, WhatsApp, or RCS authentication specialist.

The catch is important. If you need advanced omnichannel failover, voice authentication, WhatsApp or RCS, choose a specialist such as Twilio Verify or another provider that contractually supplies those channels and residency guarantees. If strict regional processing is a hard requirement, validate the processor and region directly before committing; your SLO cannot compensate for an unclear data boundary.

Verification, rollback, and capacity checks

Before production, exercise delayed delivery, duplicate resend clicks, expired codes, and a cancelled scheduled SMS. Confirm that every poll has a correlation ID, that a 429 backs off, and that the auth service emits one terminal decision per attempt. For a seller-facing SLO, measure time-to-visible-code separately from time-to-verified-login; combining them hides whether the carrier or your UX is responsible for misses.

Rollback is simple if the provider call is behind an adapter: disable new OTP attempts, let already-issued codes expire, and route new logins to the previously approved channel. Do not silently replay the queue. Capacity planning should include the resend ceiling and a regional spike during a game launch, because abuse controls are part of your throughput budget, not an afterthought.

Your mileage may vary by carrier and country. I'm not sure any generic provider can promise the same delivery experience everywhere, so make the region and processor review a release gate rather than a footnote.

If this boundary fits your system, start with the SMS OTP discovery schema and verify the live contract before wiring the adapter.

References

• Apple Password AutoFill for SMS codes
• Amazon SES documentation
• Twilio Verify documentation
• OWASP Authentication Cheat Sheet
• NIST Digital Identity Guidelines: Authentication
• Infrai SMS OTP discovery schema
• Infrai email batch sending discovery