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 →Send security alerts the owner can act on
A security alert is not a notification — it is the account owner’s chance to interrupt something in progress. Speed and clarity are the whole job, and detail is a liability.
The events worth 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 authorized
- Access revoked — a departure or a removed device
Name the event, not the account internals
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
Have an answer when they say they were never told
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 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
Your login depends on a code landing before the session expires. Connect the accounts you already pay for and the platform paces each code to the number it leaves from — so a burst of logins drains at the speed your numbers allow instead of queueing behind one shared quota.
Open →Order confirmations
The confirmation is the message your customer keeps — forwarded, screenshotted, quoted back to support. Send it the moment the order lands, on a channel they actually read, and let the log answer for it later.
Open →Shipping and delivery updates
Dispatch notices, tracking updates and delivery windows go out when the state actually changes, not on a timer. On the SMS channel the platform spreads a dispatch batch to the limit your provider applies per number, so a whole route does not stall halfway through.
Open →Appointment reminders
A reminder earns its place by arriving early enough to change a plan and saying only what the person needs to act on: when, where, and how to change it. Send a confirmation at booking and a timed reminder before, on the number they booked with.
Open →Payment reminders
The reminder that arrives before a due date is a service; the one that arrives after is a complaint notification. Send both, keep them transactional, and pace the due-date batch so it drains in a time you can plan around.
Open →Two-factor authentication
A 2FA message is triggered by a login attempt, is time-critical, and — when it arrives unexpectedly — is the earliest signal your customer gets that someone else has their password. Send it fast, word it as a warning, and keep the record.
Open →Service and incident alerts
An incident alert arrives when something is already wrong — the worst possible moment to discover your send path is down too. Keep more than one connected account on that channel, and the notice about the outage is not its first casualty.
Open →Customer feedback requests
A feedback request is marketing in everything but name, so treat it like one: one question, sent once, to people who have not opted out. That is what keeps the answers worth reading.
Open →Scope. Whaleal Platform sends 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 and pacing run on the SMS channel while logging covers every channel; consent and content stay with you.