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.
Read more →What the platform actually does
One page per capability: what it does, what it changes about your sending, and which channel it ships on. Every capability is described at the depth you need to decide whether it carries the messages your product depends on.
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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →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.
Read more →Other sections
Industries
A confirmation, a reminder, an alert, a one-time code — every industry sends the same handful of message types for different reasons. These pages describe what a given vertical typically sends, and which parts of the platform carry the load. The provider accounts, the pricing and the message credits stay yours.
Open →Use cases
Each page takes one message your product sends repeatedly and lays out what it takes to send it well: who the provider is, what the message must carry, what should never be sent, and what the platform does versus what stays with you.
Open →Compare
These pages compare architectures, not vendors. Every page works from what is true of a given approach, and the trade-offs are the point: holding your own provider relationships on one side, handing them to a platform on the other, and where an orchestration layer sits between the two.
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.