Bring your own account
The platform has no provider account of its own. That one design decision changes who owns the numbers, who holds the quota, and who appears on the invoice.
Read the guide →Sending straight from your provider vs through an orchestration 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.
What the layer adds on top of direct sending
- One integration across providers instead of one per provider, with one place every team sends from
- Cross-provider routing, failover and pacing handled at the layer rather than rebuilt by each team
- One normalised status, so a receipt means the same thing whichever account carried the message
- Suppression held in one place and applied consistently, wherever a send originates
How the layer fits alongside direct sending
The layer does not replace direct sending — it sits above it. Your provider keeps its own features and you keep one relationship; what the layer adds is the cross-provider behaviour a single direct integration cannot give you, and adopting it later is a matter of connecting accounts rather than renegotiating anything.
How the two fit together
Start direct, and add the layer when more than one team or more than one account has to send coherently. Because the accounts stay yours, the layer is a configuration you add and can remove — not a migration you commit to on day one.
Questions this usually raises
- Do we lose provider features by going through a layer?
- The layer carries the capabilities it implements for each connection, and the integrations pages list them per provider — so the answer is checkable rather than assumed. Anything the layer does not carry, your provider account still does, directly.
- Can we start direct and move later?
- Yes, and that is often the right order. Because the accounts stay yours, adopting the layer later means connecting them rather than renegotiating anything.
- What happens to our provider-specific setup?
- It stays exactly where it is. The layer sends through the account you already configured and reads status back from it, so nothing about your provider setup has to change to try it.
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 →Bringing 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 →Orchestration 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 →Several 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 →Building the layer yourself vs using one
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.
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. Comparisons here are architectural: they hold for any vendor you might choose, and depend on no third party's roadmap.