What the platform does not keep
Message content is not archived. What is kept is metadata — and among that metadata two fields are load-bearing, because without them a bill could not be reconciled.
Read the guide →Sending 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.
What triggers an alert
- Password or credential change
- Sign-in from a new device or location
- Change to recovery details or contact information
- New API key or integration authorised
- Access revoked — a departure or a removed device
Say what happened, not what was affected
The alert should name the event and point to the place where the customer can review and reverse it. Device fingerprints, locations and account internals should be resolved behind a login rather than carried in a message that passes through a provider and lands on a handset.
- Event named plainly, in the customer’s language
- A pointer to your own security page, not a deep link with a token
- No sensitive detail that would be worth intercepting
The record matters as much as the alert
When a customer says they were never told, the answer has to be the send log. The platform records each send and its status, and on the SMS channel receipts can be pushed to an endpoint you control — so the record also lives in your own system.
Questions this usually raises
- Can alerts be sent on more than one channel?
- You can connect the accounts you hold on each channel and choose which carries a given alert; a security event is a reasonable case for redundancy.
- Are these alerts suppressed by opt-out?
- No — suppression applies to promotional traffic, and a security alert is transactional.
- Can we rely on the webhook for the audit trail?
- Treat the webhook as a convenience, not the system of record. Reconcile against the message log, because callback delivery is not guaranteed.
Keep reading
What happens when your callback is down
Terminal outcomes are pushed to a URL you control, with a small bounded retry. Your handler has to tolerate a repeat, and it should not expect a call for every message.
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 →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 →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.