A timeout is not a failure
Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.
Read the guide →A send API your own service can call
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.
Endpoints are channel-scoped
Send endpoints are organised by channel, and the SMS channel is the one with a published reference today. Each channel gets the request shape its transport actually needs rather than one lowest-common-denominator call that fits none of them well.
What the API gives you
- Authenticated sends using a per-tenant API key rather than a shared account credential
- Message status readable after the send, including delivery receipts on the SMS channel
- Logs queryable so a support question can be answered from the record
Two things to design for
There is no idempotency key on the send call, so a retried request sends a second message — duplicate prevention belongs in your caller. And a send is not a transaction: the API returns acceptance, while the outcome arrives later as a receipt. Both are worth designing for before you go live rather than after.
Questions this usually raises
- Is there an SDK?
- The API is HTTP; what a caller needs is the authentication header and the request shape, both documented in the API reference.
- Can one API key send on every channel?
- Keys are per tenant, and the send endpoints themselves are channel-scoped — the API reference lists each one with its request shape.
- Does the API retry a failed send?
- No. A failed send records its error and the caller decides whether to retry — which is also why idempotency has to live on your side.
Keep reading
SMS segments and what you actually pay for
SMS is billed per segment, not per message. Whether your text fits in one segment depends on the character set it needs — and on the encoding you set on the connection.
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 →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 →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.