Short answer: for a customer-support SaaS, choose the SMS OTP design that makes delivery state, retry policy, and regional routing explicit; the simplest API is the one whose failure boundaries you can observe and enforce.
I start with the signup job, not the vendor catalog. A support agent's customer needs a verification link or code, and a delayed message looks like a broken login even when every HTTP request succeeded. My observability budget follows that distinction: every retained log line is bytes, and every label increases cardinality. Keep the event model small enough to query during an incident.
Architecture decision record: what must remain true
The decision has four invariants. A code is single-use, expires on a short server-side timer, is compared in constant time, and is never written to ordinary logs. A request is bound to a signup session and a normalized destination. The send path is asynchronous, so a carrier delay does not hold an authentication request open. Finally, a retry cannot create an unbounded message loop.
The failure boundaries matter more than a friendly SDK. Separate these states: accepted by the application, handed to a messaging provider, accepted by a carrier, and confirmed by the user. Only the last state completes verification. Store a provider message identifier as a bounded field; do not turn it into a metric label.
| Option | Useful boundary | Cost or risk | Good fit |
|---|---|---|---|
| One messaging API behind your service | Central policy, one audit trail | You own routing and fallback rules | Teams needing consistent controls across regions |
| Direct carrier integrations | Maximum routing control | Several contracts, formats, and delivery receipts | Large messaging operations with dedicated telecom staff |
| Authenticator app or passkey | Less dependence on carrier delivery | Enrollment and recovery are harder | Existing users who can complete setup |
The table is an engineering choice, not a ranking. For a first login, an authenticator that has not been enrolled is not a recovery mechanism. For a regulated workflow, SMS may also be a weak factor; NIST's digital identity guidance describes the limits of out-of-band authenticators, so document the residual risk instead of calling the channel secure by default.
Boundaries beat slogans.
How should a Node.js SaaS handle US/EU SMS OTP rate limits and retries?
Treat rate limiting as two separate controls. The first protects the account and phone number from harassment: a per-session send ceiling, a per-destination ceiling, and a cool-down after a send. The second protects your dependency: a bounded worker queue and a concurrency limit per route. An IP-only limit misses distributed abuse; a phone-only limit can punish a shared support desk.
Retry only failures that are plausibly transient. A timeout before you receive an acknowledgement is ambiguous: the message may already be on its way. Retrying immediately can produce two valid codes and two charges. Derive an idempotency key from the signup session and attempt number, persist the send result, and require a fresh attempt after the cool-down. Back off with jitter, then stop. A human-readable “try again in 30 seconds” is part of the protocol.
Short codes expire.
Consider a support signup that times out after the provider accepted the request. The worker restarts, sees no local acknowledgement, and tries again. If the adapter has no durable idempotency record, two messages arrive; if each message creates a different code, the customer cannot know which one is current. If both messages carry the same code but the audit trail stores only the last response, an investigator cannot explain the delay. The durable record therefore needs the session key, attempt number, acceptance timestamp, and terminal state, while the user-facing response stays deliberately vague. This is a little more storage than a single boolean, but it prevents a duplicate-send policy from becoming an authentication policy by accident.
Here is the critical path expressed as a generic HTTP interface. The endpoint names are placeholders for your adapter contract; the important properties are the idempotency key, a region selected from policy, and a response that records acceptance without claiming delivery.
curl -X POST https://messaging.example.test/otp/send \
-H 'Authorization: Bearer SERVICE_TOKEN' \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: signup-7f31-attempt-1' \
-d '{
"destination": "+14155550123",
"channel": "sms",
"purpose": "signup",
"region": "us",
"code_ttl_seconds": 300
}'
The application should return a neutral result to the browser whether a destination exists. Otherwise, an attacker can enumerate support customers. Keep the code out of URLs, traces, analytics events, and exception messages. On verification, count outcomes such as accepted, expired, mismatch, and rate_limited; four low-cardinality values tell you more than a raw phone number ever will.
What changes between US and EU delivery paths?
Country is a routing input, not a promise of delivery. Normalize numbers to E.164, then apply an allowlist of countries your support operation actually serves. US traffic may encounter application-to-person registration and carrier filtering; EU traffic adds privacy, consent, and data-residency questions that differ by member state and by the data processor you use. Put those assumptions in a decision record and revisit them with counsel.
Do not infer a successful login from a provider's 200 response. Capture timestamps for enqueue, provider acknowledgement, delivery receipt, and verification. Retain the minimum data needed for dispute handling, and set a deletion job with an owner. I would rather lose a decorative dashboard than retain destination identifiers forever.
Your alert should measure the conversion between states, not just API availability. A rising acknowledged_to_verified delay can indicate carrier filtering or a poor message template while all dependencies report healthy. Sample verbose payloads, but keep counters for every attempt; this is the retention trade-off that keeps an observability bill predictable.
Rejected option: blind fallback sends
I reject “send through a second route whenever the first response is slow.” It feels resilient, yet an unknown acknowledgement can create duplicate codes, confuse a user reading the newer message first, and double the audit work. A fallback is valid when the first route returns a documented, terminal rejection before acceptance, and when the same idempotency record governs both routes. It is also reasonable for a recovery flow with a different channel, provided the user explicitly chooses it.
The recommendation is unsuitable when your product needs guaranteed delivery, supports high-risk account recovery, or cannot staff regional compliance and abuse review. In those cases, stick with an enrolled authenticator or passkey as the primary factor and reserve SMS for recovery, with stronger review around the recovery event. Your mileage may vary because carrier behavior and local consent rules change; publish the assumptions beside the runbook rather than hiding them in code.
A small test and review loop
Test the adapter with deterministic fake receipts: accepted, terminal rejection, delayed receipt, duplicate acknowledgement, and worker restart after enqueue. Test the policy separately with boundary values: the first allowed send, the cool-down edge, and the attempt that must be denied. Include US and EU number fixtures without storing real destinations.
During a release, compare verification conversion and expiry rates by region, route, and application version. Keep those dimensions finite. If a new label can contain a customer identifier, it does not belong in a metric. Review the retention schedule every quarter, and remove fields that no longer answer an operational question.
Top comments (0)