A timeout is not a failure
Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.
Read the guide →Sending one-time passwords
An OTP has three requirements and no fourth: it must arrive, it must arrive before it expires, and there must be a record that it was sent. Everything else about OTP delivery follows from those three.
What the message must carry
Keep it short. A longer message is more segments, and in verification the cost is not the interesting problem — the length is, because people read codes under time pressure.
- The code itself, in a form that cannot be misread
- What the code is for, so a surprise code is recognisable as a mistake
- How long it lasts
- An instruction not to share it
Timing is the whole product
Because provider limits apply per sender number, a burst of logins can queue behind itself. Pacing is applied at the number, and a second number raises the ceiling rather than splitting the same allowance — which is why capacity planning for OTP starts with how many numbers you own, not with which plan you are on.
- Per-number pacing rather than one shared application quota
- Routing across connected accounts when one stops accepting traffic
- Delivery receipt status recorded against the send
What to send, and what to leave out
- Do not put anything else in the same message — a code plus a promotion reads as spam
- Do not depend on delivery as proof of the person; the code is the proof
- Do not retry blindly — a retried request sends a second code, because the send API has no idempotency key
Questions this usually raises
- Can a code be delivered twice by accident?
- Yes, if the caller retries. There is no idempotency key on the send API, so duplicate prevention has to live in the service that calls it.
- Will an opt-out stop verification codes?
- No. Suppression is applied to promotional traffic; transactional sends such as a code are not suppressed by the same rule.
- How fast can OTP traffic go?
- As fast as the numbers you own allow. The provider’s limit is per number, and adding numbers is what raises throughput.
Keep reading
SMS segments and what you actually pay for
SMS is billed per segment, not per message. Whether your text fits in one segment depends on the character set it needs — and on the encoding you set on the connection.
Read the guide →Order confirmations
A confirmation is the moment a customer stops wondering whether the order went through. It is also the message most likely to be forwarded, screenshot and used as a receipt, which sets the bar for what it must contain.
Open →Shipping and delivery updates
Shipping updates are bursty and unforgiving: nothing for hours, then a batch for a whole route. The failure mode is a batch that stalls halfway through, so pacing and routing do most of the work here.
Open →Appointment reminders
A reminder works when it arrives early enough to change behaviour and says only what is needed to act: when, where, and how to change it. Everything beyond that reduces the chance it is read.
Open →Payment reminders
A payment reminder sits between transactional and promotional, and where you place it decides whether it is a service or a nuisance. The useful rule: if the recipient owes the message, it is transactional.
Open →Two-factor authentication
A 2FA message is an OTP with a security context: it is triggered by a login attempt, it is time-critical, and it is the message most likely to be complained about if it arrives unexpectedly — because an unexpected one means something happened to the account.
Open →Account security alerts
A security alert is not a notification, it is an opportunity for the account owner to interrupt something. That makes speed and clarity the only two things that matter, and detail a liability.
Open →Service and incident alerts
An incident alert arrives when something is already wrong, which is the worst possible moment to discover your send path is also down. Redundancy in the messaging layer is what makes the alert dependable.
Open →Customer feedback requests
Feedback requests are marketing in everything but name, and treating them as transactional is how a service relationship turns into a nuisance. They are the clearest case for suppression and for restraint on frequency.
Open →Scope. Whaleal Messaging is an orchestration layer over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Routing, pacing and logging run on the SMS channel; consent and content stay with you.