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
For a SaaS product, messaging is infrastructure with a product surface: the login code, the incident notice, the trial-expiry nudge. These messages sit on the critical path of someone else’s workday, which sets a higher bar than marketing ever has.
The messages that sit on the 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
Build against an API, 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, with delivery receipts on the SMS channel
- Push receipt events to your own endpoint instead of polling
What stays on your side
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 behaviour is explicit rather than automatic: a failed message records its error code, and re-sending is a decision your service makes. Scheduling and bulk behaviour are documented in the help centre.
- 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 is mostly a messaging operation that happens to have a checkout. The confirmation, the dispatch note, the delivery window, the code for a failed payment — these are the messages customers actually read, and they run on the same few send paths every day.
Open →Fintech & payments
In payments, the message is often the product: a code that must arrive before a session expires, an alert that proves a transaction happened, a reminder that keeps a subscription alive. Latency and duplicates matter here more than anywhere else.
Open →Healthcare & clinics
Most healthcare messaging is administrative, and administrative is exactly where a missed message costs a wasted appointment slot. The discipline is to say just enough to be useful and nothing that belongs in a clinical record.
Open →Logistics & delivery
A delivery operation lives on contact attempts: the customer who is not home, the gate code nobody has, the parcel going back to the depot. Each of those is a message that either saves a second attempt or causes one.
Open →Education & training
Education messaging is overwhelmingly about timing: a class that moved, a deadline that is close, an enrolment that has not been confirmed. The failure mode is not a missing message, it is a message that arrives after it matters.
Open →Marketplaces & platforms
A marketplace sends to two audiences who care about the same event for opposite reasons: the buyer wants it to arrive, the seller wants proof that it did. That makes receipts and auditability the interesting part of the problem.
Open →Travel & hospitality
Travel messaging is time-zone-shaped: a confirmation that must arrive immediately, a reminder that should arrive the evening before, and a disruption notice that is worthless if it arrives after the guest has left for the airport.
Open →On-demand & field services
Field service messaging is measured in minutes: a technician is twenty minutes away, a job has moved, a customer will not be in. Every one of these messages exists to avoid a wasted trip.
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. Sector-specific rules — consent, records retention, industry obligations — stay with you and your provider.