Routing and failover
Routes are ordered by priority and weighted within a connection. The point of the arrangement is that a provider rejecting sends degrades into slower sending, not into silence.
Read the guide →Several connected SMS accounts vs a single provider account
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.
What a second connected account gives you
- Automatic failover when one account stops accepting traffic — the message moves instead of failing
- Throughput that genuinely grows, because pacing is applied per sender number and each account brings its own
- Coverage across destinations where a single account cannot hold every identity
- One routing decision, configured once, instead of a single default path you hope holds
What it takes to hold two accounts well
- Two registrations to keep current — the console keeps them visible rather than hiding them behind one number
- Receipts and logs matter more with two accounts, which is why normalisation is part of the layer rather than an add-on
- Failover only helps when accounts fail independently — two numbers on the same provider is not resilience
How to sequence it
Start with one account and take it end to end. Add the second when a specific ceiling — a per-number limit, an outage, a destination you cannot reach — is the thing standing in your way. The layer is built so that connecting the second account is the whole change.
Questions this usually raises
- Is failover available on every channel?
- Automatic failover between connected accounts ships on the SMS channel today — the channel where a provider-side outage is the failure that costs you messages. Email and WhatsApp carry their own provider-side limits and are handled by those channels.
- Does more accounts mean less pacing discipline?
- No — that is the point. Pacing still applies per sender number, so more numbers raise the ceiling rather than removing the limit.
- Do we need two accounts to use the platform?
- No. One account is a fully supported setup; the second is there for the day you want failover rather than a single path.
Keep reading
Which rate limit you just hit
There are two throttles in front of a send: the one your plan sets, and a much higher one at the network edge. Both answer with the same status code, so the message text is what tells them apart.
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 →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.