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.
Read more →Send the messages your product already depends on
Each page takes one message your product sends repeatedly and lays out what it takes to send it well: who the provider is, what the message must carry, what should never be sent, and what the platform does versus what stays with you.
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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →Other sections
Industries
A confirmation, a reminder, an alert, a one-time code — every industry sends the same handful of message types for different reasons. These pages describe what a given vertical typically sends, and which parts of the platform carry the load. The provider accounts, the pricing and the message credits stay yours.
Open →Features
One page per capability: what it does, what it changes about your sending, and which channel it ships on. Every capability is described at the depth you need to decide whether it carries the messages your product depends on.
Open →Compare
These pages compare architectures, not vendors. Every page works from what is true of a given approach, and the trade-offs are the point: holding your own provider relationships on one side, handing them to a platform on the other, and where an orchestration layer sits between the two.
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.