The list we keep off your roadmap
- Per-number pacing, at the limit your provider actually applies to the number
- Failover across accounts, plus telling an outage from a bad route (SMS channel)
- Receipt normalization, so you read one status instead of every provider’s vocabulary
- Suppression that catches opt-outs exactly, and does not catch them by accident
- Logs that answer a support question while holding metadata rather than message bodies
- A record of what was sent, per recipient, provable after the fact
Why this is worth buying rather than building
None of it is hard in isolation. Each item is discovered from an incident, fixed under pressure, and then maintained as providers change their behavior. Buying the layer is how that maintenance stops being your team’s problem — and how nobody gets paged at 3am for a provider’s rate-limit change.
Keep the parts that are yours
Your application still owns the decision to send, the content, and the record that matters to your business. You can route some traffic through the layer and leave the rest direct — the accounts stay yours, so the choice is reversible at any point.
Questions this usually raises
- Can we use the platform for some traffic and direct for the rest?
- Yes. The platform connects to accounts you already have, so a subset of traffic can route through it while the rest continues unchanged.
- Is there an open API?
- Yes — sends go over HTTP with per-tenant keys, and the SMS channel is the published reference today. The API reference lists each endpoint with its request shape.
- What does the platform take off my team’s plate?
- A specific list of responsibilities — pacing and failover on the SMS channel, receipt normalization, suppression and logs — maintained as providers change their behavior. Everything else, including your own product, stays with your team.
Keep reading
5 minPacing, quotas and why we queue
Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.
Read the guide →4 minA 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 →CompareBringing your own provider vs buying credits
We connect to the provider accounts you already pay for, and we never sell you message credits. That one decision sets your rate, your switching cost, and who owns the relationship — everything below follows from it.
Open →CompareOrchestration layer vs becoming your own BSP
We chose to sit above the provider APIs rather than hold carrier relationships — because that is the arrangement that keeps your rates, your registrations and your sender identity in your own name. Here is what that choice puts in your hands.
Open →CompareSeveral connected accounts vs one
A single account is a single point of failure you cannot see breaking until customers tell you. Connecting a second turns that into failover you configure once — which is why routing belongs in the layer rather than bolted on later.
Open →CompareSending straight from a provider vs through a layer
Sending direct is the fastest way to send the first message. The layer is what keeps messaging dependable once a second provider, a second team or a second failure arrives — and it adds nothing you have to migrate away from.
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. Comparisons here are architectural: they hold for any vendor you might choose, and depend on no third party's roadmap.