Duplicate OTP Sent? Causes and Fixes
Why users receive two OTPs for one request: client retries, queue duplicates, network race conditions. How idempotency keys solve the problem.
Duplicate OTPs annoy users, waste your wallet, and trigger fraud flags. Almost always the cause is a missing idempotency key.
Causes of Duplicate OTPs
- User taps “send” twice in quick succession.
- Network failure → client retries → both succeed.
- Background queue worker re-emits.
- Race between primary and secondary route.
Client Retries
Mobile networks routinely retry HTTP requests on flaky connections. Without idempotency keys, every retry that lands costs an extra OTP.
Queue Duplicates
At-least-once queues (SQS, Pub/Sub) can deliver the same job twice. Worker must idempotency-key on the job ID.
Race Conditions
Failover routes that both succeed before the failover marker propagates.
The Fix: Idempotency Keys
POST /otp/send
{ "phoneNumber": "+91...", "idempotencyKey": "<uuid>" }Same key = same response, no second SMS. See our idempotency guide.
FAQ
StartMessaging supports idempotency keys natively — pass one and we deduplicate for you.
StartMessaging Team
StartMessaging Team