Plans, quotas and billing
What each tier includes, how a "channel" is counted, and why your SMS fees never appear on our invoice.
Read this article →Getting started
Connect a provider, issue a key, send your first message — and meet the two defaults that quietly cost money if you miss them.
What you get
Whaleal Messaging is a sending layer in front of the provider accounts you already own. You keep your CPaaS contracts, your sender numbers and your delivery reputation; the platform adds a console and a message log for the connections you make, with the send API documented per channel.
- HTTPS endpoints to send over the connected accounts, documented per channel.
- Weighted routing and automatic failover across providers and sender numbers.
- Delivery receipts and terminal status pushed back to a callback URL you control.
- Opt-out suppression that blocks marketing sends to a number that replied STOP.
- A metadata-only message log, retained per your plan.
Scope. Everything described in these articles is the SMS channel. Email and WhatsApp connect on the same model — link your own provider account and send from the console.
Set up in three steps
All three live in the console, and all three are required. Miss one and a send is rejected rather than silently dropped — which is the behaviour you want.
Connect a provider
Channels → Add connection. Paste the credentials of a CPaaS account you already hold. Six providers can be connected today: Twilio, Vonage, Infobip, MessageBird, Plivo and AWS End User Messaging.
Issue an API key
Developer → Create key. The full key is shown once, shaped sk_…. Copy it immediately; it cannot be displayed in full again.
Bind the key to a channel
On the same page, select the channels this key may send over. A key with no binding is rejected with a 400-class error — there is no "all channels" fallback.
Send your first message
With a key in hand, a single call is enough:
| Item | Value |
|---|---|
| Method and path | POST /open/v1/sms/send |
| Base URL | https://api.whaleal.com/open/v1 |
| Auth header | Authorization: Bearer sk_… (or X-API-Key) |
| Body | {"to":"+14155550123","content":"Your code is 4481","messageType":"TRANSACTIONAL"} |
Note. A success response means the platform accepted the message, not that a handset received it. To learn the real outcome, either poll GET /open/v1/sms/{messageId} or configure a callback URL.
Two defaults that cost money
Both are easy to make once and hard to notice, because neither produces an error.
- Omitting messageType on verification codes and order confirmations. The default is MARKETING, so a recipient who has opted out will have their verification code suppressed. Declare TRANSACTIONAL or INFORMATIONAL on anything that is not a promotion.
- Retrying after a client-side timeout. The platform does not de-duplicate: a retry is a second message, sent and billed. See "Messages are accepted but not arriving".
Keep reading
Connect your own provider account
Bring-your-own-account keeps the agreement, the sender reputation and the invoice with your CPaaS provider. Here is how to connect one, and what changes once you do.
Read this article →Sender numbers and how they are chosen
Most senders never specify a from address, and that is usually correct. Here is when to override it.
Read this article →