OTP rate limits and abuse protection

Threats addressed by rate limits

OTP has two primary abuse classes. Bulk send calls consume balance, create unwanted messages, and increase support load. Repeated verify calls attempt to guess a valid six-digit code.

One shared threshold handles both poorly. Sending usually needs a noticeable cooldown, while verification should tolerate a few human errors but stop automated guessing quickly.

Send limits

A server-enforced resend cooldown is essential. A frontend countdown improves usability but does not protect the API because an attacker can bypass the interface.

Combine counters by phone number, account or session, IP and possibly subnet, API key or company, verification purpose, and total volume across short and long windows.

A short window catches bursts while a longer window catches slower distributed abuse. Choose thresholds from product risk and observed traffic instead of copying arbitrary values.

Verify limits

A six-digit code has a finite search space. Bind each attempt to the phone, active challenge, and purpose. After repeated failures, increase delay or invalidate the challenge.

Do not permit unlimited guesses during the five-minute TTL. Expiration limits time, not the number of attempts inside that time.

A successfully verified code must become invalid immediately and cannot confirm the action twice.

Why IP-only limiting fails

An office, mobile network, or NAT can place many users behind one public IP. A strict address-only threshold causes false blocks, while an attacker can distribute traffic across addresses.

IP remains useful as one signal when combined with phone, account, key, and behavioral indicators.

Handle 429 correctly

HTTP 429 Too Many Requests means an immediate retry is not allowed. The client should stop its loop, retain the request ID, show a clear countdown, wait for the permitted interval, and retry only a bounded number of times.

For temporary 5xx responses, use exponential backoff with a cap and small jitter. Retrying 401 or most 422 responses without changing the request is ineffective.

Safe user experience

Disable resend until the cooldown completes. Prevent parallel requests and update the timer only after the server responds.

Error text should not reveal account existence. Tell users when they can retry without publishing internal protection thresholds.

Monitoring

Track send and verify volume, the share of 429, 422, and 401, abnormal phone numbers or keys, credits consumed without verification, resend frequency, verification success, and traffic concentration by network.

Alerts should lead to an action: temporarily restrict a key, contact the company, investigate secret exposure, or adjust an overly strict threshold.

Implementation checklist

• Send and verify have independent rules.
• Cooldown is enforced by the server.
• Counters combine phone, account, IP, key, and purpose.
• Verification attempts are capped inside the TTL.
• Successful codes cannot be reused.
• A 429 does not trigger immediate retry.
• Temporary 5xx uses bounded backoff.
• The UI displays timing without exposing thresholds.
• Abuse and unusual balance use trigger alerts.

See the rate-limit reference, API errors, and the broader OTP security guide.