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 →Using an 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.
What we do, and what that keeps yours
- We add routing, pacing, normalised receipts, suppression and logs above the accounts you already hold
- Carrier relationships and registrations stay with your provider, filed in your name
- Nothing in the middle can reprice your traffic or lift a carrier filter
- Your volume commitments and your sender identities are never held by us
What holding carrier relationships actually requires
Holding carrier relationships is a permanent engineering and regulatory commitment — registrations, sender verification, country rules, and commercial liability for delivery. Those obligations exist in both models; becoming a BSP adds the sending platform on top of them rather than replacing them.
- Standing up senders is the easy part of either route
- The hard part is the permanent obligations, which do not disappear when you self-host
- Receipt normalisation is ongoing work, because each provider reports in its own vocabulary and changes it
Built for teams whose product is something else
The layer is built for teams whose product is something else: it keeps messaging dependable without letting it become the business. If messaging is itself what you sell, owning the carrier relationship may well be the point, and the layer still sits above it — the two arrangements are not exclusive, and choosing this one does not stop you from holding relationships of your own.
Questions this usually raises
- Does Whaleal hold a carrier relationship?
- No, and that is deliberate. Staying above your provider is what keeps your rates, your registrations and your sender identity in your own name rather than in ours.
- Will the platform file registrations for me?
- Registration and sender verification are filed by you, in your own name — which is exactly why they stay with you whichever way you send.
- Is self-hosting cheaper?
- It depends what you count. What the layer takes off your plate is the permanent part: the engineering attention a sending platform needs after the first message works — pacing, failover, receipt normalisation and suppression as providers change.
Keep reading
Reading a delivery receipt
A receipt is a sequence of states, not a verdict. Treating an intermediate one as final is the most common way a sending dashboard ends up lying to you.
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 →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 →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.
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.