Calling a provider API takes an afternoon. Making messaging dependable is a list of unglamorous problems that only show up in production — and that list is what we maintain so your team does not have to.
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 normalisation, 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 behaviour. 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, failover, receipt normalisation, suppression and logs — maintained as providers change their behaviour. Everything else, including your own product, stays with your team.
Keep reading
5 min
Pacing, 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.
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.
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.
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.
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.
Sending 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.
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. Comparisons here are architectural: they hold for any vendor you might choose, and depend on no third party's roadmap.