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 →Connect the provider accounts you already pay for
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.
Connections are per channel
A connection holds the credentials for one provider account on one channel. An SMS connection, an email connection and a WhatsApp connection each carry their own credentials, their own limits and their own receipts — they are not one generic “channel” object with a type field.
- SMS — the providers the console can connect today, each with the credential fields your provider actually requires
- Email — your own sending account with that provider
- WhatsApp — your own business account and its credentials
Your contract, your pricing, your numbers
Because the account stays yours, so do the volume commitments, the rates and the sender identities attached to it. Nothing is repriced on the way through, and the connection never gives the platform control of your provider contract.
- No markup on message credits — you pay your provider directly
- Your existing sender numbers and registrations stay attached to your account
- Disconnecting a provider leaves your account untouched
What stays with your provider
A connection gives the platform a send path, not control of your account. Registering a sender ID, raising a provider quota and approving a WhatsApp template are provider-side actions that stay with your team and the provider you already work with — which is also why they cannot be skipped by connecting here.
Questions this usually raises
- Do I need to move my numbers or traffic to you?
- No. The accounts stay with your provider; the platform is given credentials so it can send through them and read status back.
- Can I connect more than one account on the same channel?
- Yes, and that is the point — multiple connected accounts on one channel are what makes routing and failover possible.
- What credentials does a connection need?
- Each provider lists the fields it requires, and the console only asks for those. Credential requirements per provider are documented in the integrations section.
Keep reading
Who the recipient actually sees
If you do not name a sender, the platform picks one from the connection that carries the message. Naming one explicitly takes priority everywhere.
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.
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.