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 →Messaging for SaaS and online services
Your login codes, incident notices and renewal nudges sit on the critical path of someone else’s workday. Send them from your own service with a tenant API key, and read the outcome back through the same API.
The messages on your users’ critical path
- Two-factor and verification codes
- Security alerts — new device, password change
- Incident and maintenance notices to affected accounts
- Trial expiry and onboarding nudges
- Renewal and seat-change reminders
Send from your code, not a console
Product messaging is generated by your application, not typed by a human. The platform exposes an open API for sending, with per-tenant API keys, so the code that emits the event is the code that sends the message. The console is there for operational sends and for looking at what happened.
- Send from your own service with a tenant API key
- Read message status back through the API — acceptance, and the delivery status wherever the provider reports it
- Push receipt events to your own endpoint instead of polling
Your notification policy stays yours
Which of your users may be messaged, how often, and what a message is allowed to say — that is your product decision. On the SMS channel the platform applies the routing, pacing and suppression rules you configure; it does not decide your notification policy.
Questions this usually raises
- Can I send the same code from two services without duplicating it?
- Not automatically. The send API has no idempotency key, so a retried call produces a second message. Duplicate suppression has to live in the caller.
- Do you retry a failed send for me?
- Retry behavior is explicit rather than automatic: a failed message records its error code, and re-sending is a decision your service makes. Scheduling and bulk behavior are documented in the help center.
- Can receipts be pushed to our own webhook?
- Yes — the platform can push delivery receipt events to an endpoint you configure. The reliability caveats for callbacks are covered in the guides.
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 →E-commerce & retail
A storefront runs on the messages customers actually read: the confirmation, the dispatch note, the delivery window, the code after a failed payment. Send all of them over the SMS, email and WhatsApp accounts your store already pays for.
Open →Fintech & payments
In payments the message is often the product: a code that has to land before the session expires, an alert that proves a transaction happened, a reminder that keeps a subscription alive. Connect your own accounts, and the send path stops being the part you have to watch.
Open →Healthcare & clinics
Most clinic messaging is administrative, and a missed administrative message costs a wasted appointment slot. Send a confirmation at booking and a timed reminder before, on the number the patient gave you — and keep clinical detail out of it.
Open →Logistics & delivery
A delivery operation lives on contact attempts: the customer who is not home, the gate code nobody has, the parcel heading back to the depot. Each of those is a message that either saves a second trip or causes one.
Open →Education & training
Education messaging is about timing: a class that moved, a deadline that is close, an enrollment nobody confirmed. The failure mode is not a missing message — it is one that arrives after it mattered.
Open →Marketplaces & platforms
A marketplace messages two audiences about the same event for opposite reasons: the buyer wants it to arrive, the seller wants proof that it did. That makes the receipt the part worth getting right.
Open →Travel & hospitality
Travel messaging is shaped by the clock: a confirmation that has to arrive immediately, a reminder the evening before, a disruption notice that is worthless once the guest has left for the airport. Send each one from an account that is still accepting traffic.
Open →On-demand & field services
Field service messaging is measured in minutes: a technician twenty minutes away, a job that moved, a customer who will not be in. Send the ETA when the event happens and it saves a trip; send it late and it is worse than silence.
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. Sector-specific rules — consent, records retention, industry obligations — stay with you and your provider.