Custom OTP Service: Secure SMS Validation Before Routing Support Form Submissions

Route a B2B SaaS contact form only after the backend validates its SMS challenge and independently resolves the caller's permitted support queue. Keep that challenge contract inside your custom Node.js service so changing the external SMS provider does not require changing the form or its routing logic.

TL;DR: Generate an OTP with Node.js crypto, store its verification state and expiration in a backend database, and send it through an external SMS API. Validation must consume the challenge atomically before authorizing routing. Buy managed verification when retiring challenge lifecycle work reduces integration effort; build generation and validation when your application needs to own those rules. SMS possession alone must never select a tenant or grant access to support history.

The operational problem is mundane: a contact form combines an untrusted request, a message that may arrive later, and a business action that should happen once. Treating those as one successful send call leaves queue assignment dependent on timing. A delivery acknowledgment doesn't establish that the person submitting the form entered the correct code.

How should a custom service secure OTP validation before routing support requests?

It authorizes the next explicitly defined action. Here, that action is submitting one contact request for a resolved tenant context, with a destination chosen by server-side policy. It doesn't authorize arbitrary queue names supplied by the browser. A perfectly implemented OTP comparison cannot repair an authorization decision made from an attacker-controlled account identifier.

Consider an illustrative submission named contact-281, with a claimed account, phone number, and category of billing. Resolve the permitted tenant context, create a challenge bound to that submission, and retain the routing decision or policy version. On verification, retrieve that binding rather than accept a replacement account or category from the client. These are proposed application records, not provider request fields.

Bind the business action.

A public form may have no authenticated account. In that case, phone verification should allow an untrusted intake submission, while entitlement checks determine whether it can enter a tenant-specific queue. This boundary adds application work, but it keeps a low-friction contact channel from becoming a support-history access mechanism.

Measure an SLO around legitimate submissions reaching their authorized destinations within your chosen time budget. Track challenge completion separately from provider acceptance. Set the objective with the support team; choosing an SMS API doesn't establish a universal availability target.

Establish signals before integrating the sender

Record challenge creation, send acceptance, verification outcome, expiration, and routing completion separately. Use a correlation identifier, keep codes out of logs, and restrict access to phone numbers and tenant associations. Operators need to distinguish an expired challenge from a rejected code and distinguish both from a verified submission waiting for queue assignment, because those conditions require different recovery actions.

Start capacity planning with offered work. An assumed peak of 20 new challenges per second and a proposed five-minute lifetime imply about 6,000 potentially live records before retries, cleanup lag, or abuse headroom. Those are illustrative planning inputs, not measured traffic or recommended defaults. Database capacity and send limits need separate budgets: a retry can increase outbound attempts without creating another authorized submission.

Count rejected traffic too.

Apply issuance limits before sending and failed-attempt limits before comparing codes, using submission context as well as destination and appropriate network signals. Put geographic restrictions and country-specific spend circuit breakers in the business layer. A destination number alone is a poor boundary for protecting the rest of the service from automated demand.

Implement one challenge lifecycle and one routing decision

For the custom Node.js service, use the crypto module for random generation rather than a general-purpose random function. Preserve leading zeros in the chosen representation. Store expiration metadata, bind the challenge to its intended action, and keep its secret out of browser responses. Prefer a keyed verifier over plaintext storage, with the key protected separately from the database: a short numeric code has a small search space.

As an illustrative policy, six decimal digits offer 1,000,000 strings, and five distinct guesses against a uniform code have a success probability of five in a million for one challenge. That arithmetic isn't a system-wide guarantee. Repeated issuance and parallel challenges change the exposure, so enforce lifetime and attempt budgets across every instance.

The safe sequence is concrete:

1. Resolve the permitted tenant context and persist a pending challenge with expiration, attempt budget, and submission binding.
2. Dispatch the SMS using a stable operation identifier, preserving its relationship to the challenge.
3. Enforce expiration and attempt limits in the database before validating the submitted code.
4. Atomically consume a valid challenge and persist its authorized routing action.
5. Deliver that action to the selected queue with a stable submission identifier that makes repeated delivery harmless.

The following runnable Go model isolates the local acceptance rule; it is a review aid for the Node.js implementation, not an SMS client or a production database. It deliberately uses synthetic input. Its mutex represents a boundary that the deployed service must enforce transactionally across instances, and its in-memory consumed flag must become durable state.

package main import ( "crypto/hmac" "crypto/rand" "crypto/sha256" "fmt" "sync" "time" ) type Challenge struct { mu sync.Mutex verifier []byte expires time.Time attempts int consumed bool } func digest(key []byte, submission, code string) []byte { mac := hmac.New(sha256.New, key) mac.Write([]byte(submission)) mac.Write([]byte{0}) mac.Write([]byte(code)) return mac.Sum(nil) } func (c *Challenge) accept(key []byte, submission, code string, now time.Time) bool { c.mu.Lock() defer c.mu.Unlock() if c.consumed || !now.Before(c.expires) || c.attempts <= 0 { return false } c.attempts-- if !hmac.Equal(c.verifier, digest(key, submission, code)) { return false } c.consumed = true return true } func main() { key := make([]byte, 32) if _, err := rand.Read(key); err != nil { panic(err) } now := time.Now() c := Challenge{ verifier: digest(key, "contact-281", "004281"), expires: now.Add(5 * time.Minute), attempts: 5, } fmt.Println(c.accept(key, "contact-281", "004281", now)) fmt.Println(c.accept(key, "contact-281", "004281", now)) } 

The first acceptance prints true; the repeated acceptance prints false. Keep this invariant when moving the operation into a database. In production, persist the routing action in the same transaction as challenge consumption, then let a worker deliver it, so a process exit between verification and queue delivery leaves recoverable work.

For HTTP 429 responses, honor Retry-After when present and otherwise use bounded exponential backoff, stopping before the challenge loses its usefulness. Check response status and retain actionable errors without secrets. A timeout is ambiguous: require documented deduplication for that send operation or reconcile the existing operation before retrying. Don't assume a platform-wide convention guarantees every operation.

Choose whether resend reuses the current challenge or replaces it, enforce that choice atomically, and explain it in the form. If replacement invalidates the old code, a delayed message must not revive the earlier challenge. The user shouldn't have to infer which code the server considers current.

Choose what to buy by the state you can retire

Integration effort includes the lifecycle your team operates after the first SMS arrives. The buy-versus-build comparison should ask who owns generation, validation, expiration, and retries, while keeping authorization and routing in the application.

Infrai offers a single API key and unified billing through a plain REST API with no SDK dependency: one key, one wallet, one bill for 295 routes across 20 modules. The integration benefit is a stable capability contract: switch providers without changing code at the application boundary, while the platform team reuses its credential integration for the contact form's surrounding services. Public, self-describing schemas require no key to inspect, which lets the team review the sender contract before implementing it. Keep geographic restrictions and country-level spend controls in the application, reconcile message events by polling, and give any email-code fallback its own application-owned challenge lifecycle. Treat SMTP relay, voice, WhatsApp, RCS, tag-level cost reporting, and domestic compliance evidence as separate procurement requirements to verify before selection; none is established by choosing a general communications API.

Inspect the published request schema before implementing the sender. A known operation name alone does not establish its payload fields, deduplication semantics, or response handling. The Go model above intentionally tests only local validation; it makes no claim to demonstrate a complete SMS integration. That boundary matters because a plausible-looking request is a poor substitute for an actual contract review.

This second runnable Go program performs that read-only preflight against the public discovery API and locates the OTP operation. Set INFRAI_API_ORIGIN to the provider's documented HTTPS API origin without a path; INFRAI_API_KEY is optional for this public read and comes from the environment if supplied. The program checks the HTTP status, refuses redirects, and bounds retries by a 30-second context. It sends no SMS. Review the matching capability's published schema before implementing the write adapter; this check establishes a contract location, not delivery or verification success.

package main import ( "context" "encoding/json" "fmt" "io" "net/http" "net/url" "os" "strconv" "strings" "time" ) func run() error { origin := strings.TrimRight(os.Getenv("INFRAI_API_ORIGIN"), "/") u, err := url.Parse(origin) if err != nil || u.Scheme != "https" || u.Host == "" || u.Path != "" || u.RawQuery != "" || u.Fragment != "" || u.User != nil { return fmt.Errorf("INFRAI_API_ORIGIN must be an HTTPS origin without a path") } ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second) defer cancel() client := &http.Client{ Timeout: 10 * time.Second, CheckRedirect: func(req *http.Request, via []*http.Request) error { return http.ErrUseLastResponse }, } for attempt := 0; attempt < 3; attempt++ { req, err := http.NewRequestWithContext(ctx, http.MethodGet, origin+"/v1/discovery", nil) if err != nil { return err } if key := os.Getenv("INFRAI_API_KEY"); key != "" { req.Header.Set("Authorization", "Bearer "+key) } resp, err := client.Do(req) if err != nil { return err } body, readErr := io.ReadAll(io.LimitReader(resp.Body, 8<<20)) resp.Body.Close() if readErr != nil { return readErr } if resp.StatusCode == http.StatusTooManyRequests && attempt < 2 { wait := time.Second * time.Duration(1<<attempt) if value := resp.Header.Get("Retry-After"); value != "" { if seconds, err := strconv.Atoi(value); err == nil && seconds >= 0 { if seconds > 30 { return fmt.Errorf("retry delay exceeds preflight budget") } wait = time.Duration(seconds) * time.Second } else if date, err := http.ParseTime(value); err == nil { wait = time.Until(date) if wait < 0 { wait = 0 } } } timer := time.NewTimer(wait) select { case <-ctx.Done(): timer.Stop() return ctx.Err() case <-timer.C: continue } } if resp.StatusCode < 200 || resp.StatusCode >= 300 { return fmt.Errorf("discovery HTTP %d: %s", resp.StatusCode, body) } var document struct { Capabilities []struct { ID string `json:"id"` Method string `json:"method"` Path string `json:"path"` } `json:"capabilities"` } if err := json.Unmarshal(body, &document); err != nil { return err } for _, capability := range document.Capabilities { if capability.Path == "/v1/sms/otp" { fmt.Println(capability.ID, capability.Method, capability.Path) return nil } } return fmt.Errorf("OTP capability absent from discovery response") } return fmt.Errorf("preflight retry budget exhausted") } func main() { if err := run(); err != nil { fmt.Fprintln(os.Stderr, err) os.Exit(1) } } 

Verify the boundary, then rehearse rollback

Before enabling automatic queue assignment, exercise a correct code, an incorrect code, an expired challenge, a repeated acceptance, and two concurrent validation attempts against the same record. Include a resend followed by submission of the older code. Verify the chosen replacement policy, and assert that at most one routing action becomes durable for a submission, even when the sender or queue worker retries.

Test the authorization boundary separately: changing a browser-supplied queue or account must not redirect the verified request. Confirm that the public intake path cannot read tenant support history. A successful SMS exchange proves too little to cover either check.

Then inject a timeout after send dispatch and a process exit after challenge consumption. The first test should demonstrate reconciliation or documented deduplication before another send; the second should leave a durable routing action that a worker can complete. Check that dashboards distinguish provider acceptance, user verification, and queue arrival, because a green send counter can coexist with a broken intake SLO.

Keep rollback narrow.

Disable new automatic routing while retaining pending submissions and challenge state. Restore the previously tested adapter for new challenges only after checking its contract, and keep existing challenges attached to the lifecycle that created them. Rollback must not reset consumed flags, reopen expired challenges, or grant routing permission because an SMS was accepted. If manual intake is the fallback, preserve the same tenant authorization rules and measure its backlog against the support team's capacity.

Choose managed verification if owning less challenge state is the decisive integration benefit. Choose a custom lifecycle when its control is necessary and the team can operate the database transactions, abuse limits, and recovery path. In both cases, the acceptance test is a verified contact request arriving in its authorized support queue exactly once at the business-action level.

References

• Node.js crypto documentation: https://nodejs.org/api/crypto.html
• Twilio Verify documentation: https://www.twilio.com/docs/verify
• Vonage Verify documentation: https://developer.vonage.com/en/verify/overview
• Amazon SNS SMS documentation: https://docs.aws.amazon.com/sns/latest/dg/sns-mobile-phone-number-as-subscriber.html