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 →Routing and automatic failover
One provider account is a single point of failure that you cannot see failing until customers tell you. Routing across several accounts turns that into a failover you configure once.
Built end to end on the SMS channel
Automatic failover between connected accounts ships on the SMS channel — the channel where provider-side failures are the ones that hurt: a number throttled, an account suspended, a route that quietly stops accepting traffic. That path is built end to end, which is why this is where the feature lives.
What routing changes
Failover changes which provider carries a message. The destination carrier still decides whether it lands, and a route that is wrong on every account still has to be fixed at the source — because there would be nowhere left to route to.
- A single send can be carried by any of your connected SMS accounts
- An account that stops accepting traffic is taken out of the route
- A problem that affects every account surfaces instead of hiding behind a retry
How it works together with pacing
Failover and pacing solve different problems: pacing keeps you under the limit a provider applies per number, failover keeps traffic moving when an account stops working. Configure both, and neither failure mode is left open.
Questions this usually raises
- Is failover available for email or WhatsApp?
- Failover across connected accounts ships on the SMS channel today. Email and WhatsApp carry their own provider-side limits and are handled separately.
- Does failover guarantee delivery?
- No. It changes the provider carrying the message. Delivery still depends on the destination network accepting it.
- What decides the order accounts are tried in?
- Routing works across the accounts you have connected for that channel. The mechanics and their limits are described in the routing guide rather than restated here.
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 →Bring-your-own provider connections
You keep the provider relationship you already have, connect it once, and the platform treats that account as a send path it can route through, pace against and read receipts from.
Open →Normalised delivery receipts
Two providers describe the same outcome with two different words, and neither word means what the reader assumes. Normalising receipts into one status is what makes a receipt usable in code rather than as a screenshot.
Open →Opt-out and suppression
Suppression is the part of messaging that is easy to get almost right and expensive to get wrong: honour it too broadly and confirmations stop arriving; honour it too narrowly and you are ignoring a customer who asked you to stop. Getting it right is the whole feature.
Open →Pacing at the provider’s real limit
The limit that stops your traffic is not your application’s quota — it is the rate your provider applies per sender number. One number, one limit, and a batch that ignores it fails partway through.
Open →Sender identity you own
The sender is the first thing a recipient sees and the thing that decides whether a message is trusted. Because that identity sits on your own account, it stays with you however you choose to send.
Open →Send API
Product messaging is emitted by code, not typed by a person. The API exists so the service that knows an event happened is the service that sends the message about it.
Open →Receipt webhooks
Polling for status works until the volume makes it wasteful. A callback lets the system that cares about an event be told about it, which also means the record lands in your own database at the same time.
Open →Message logs and usage
The first question after any messaging incident is “what did we actually send?”. That answer should come from a log with a filter on it, not from a reconstruction.
Open →Tenant isolation
Isolation is the feature that nobody asks about until it is missing. Holding connections, keys and records per tenant means a shared platform does not become a shared inbox.
Open →Manual sending from the console
Not every message comes from an API. Testing a new sender, resending after a fix, or simply looking up what a customer received — those are console jobs, and they should not require writing code.
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. Each page states the channel a capability ships on, so you can plan against what is available today.