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 →Two-factor authentication messages
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.
What makes a 2FA message good
- The code, formatted so it is easy to transcribe
- A plain statement of what triggered it
- An explicit “if this was not you” instruction
- Nothing else — no links to anything other than your own domain
The unexpected-code case is a feature
If a message arrives that the customer did not request, it is the earliest signal available that someone else has their password. Wording it as a warning rather than a nuisance is what turns the message into a security control instead of a support ticket.
Volume and timing
Login traffic is spiky and unpredictable. On the SMS channel, pacing is applied per sender number and routing can move traffic to another connected account, so a spike is absorbed as a delay rather than a wave of failures.
- Per-number pacing instead of one shared quota
- Failover across connected SMS accounts
- Every send logged, so an incident can be reconstructed
Questions this usually raises
- Can a 2FA code be suppressed by an opt-out?
- No. Suppression applies to promotional traffic; a login challenge is transactional and is not filtered by the same rule.
- Should 2FA and marketing go out from the same number?
- That is a sender-identity decision. Keeping security traffic on a number that only sends security traffic makes an unexpected message easier for the customer to interpret.
- What records are kept?
- Each send is logged with its status, and delivery receipts are recorded on the SMS channel, so an incident review works from a record rather than a recollection.
Keep reading
Which rate limit you just hit
There are two throttles in front of a send: the one your plan sets, and a much higher one at the network edge. Both answer with the same status code, so the message text is what tells them apart.
Read the guide →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.
Open →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 →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.