What the platform does not keep
Message content is not archived. What is kept is metadata — and among that metadata two fields are load-bearing, because without them a bill could not be reconciled.
Read the guide →A record of every send, and what it cost you
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.
What the logs hold
- Each send with its channel, connection and status
- Failure reasons where the provider returned one
- Delivery receipt status once it arrives
- Filtering so a single recipient or time window can be isolated
Usage follows the same record
Usage is derived from the same log rather than counted twice, so a number in a usage view and a number in a filtered log cannot disagree. Segment counts matter here: a long message is several segments and is billed as such, which is why the segmentation guide is worth reading before estimating cost.
The log holds metadata, not content
The message log stores metadata only — time, destination number, tenant, provider, sender identity, normalised status, provider message ID and raw error code. Message bodies are not persisted, which keeps a log of your customers’ messages from turning into a second copy of their conversations to govern, export and delete.
- Stored — time, destination, provider, sender identity, status and error code
- Not stored — the message body
- Retention applied to the metadata through a time-to-live, per your plan
Questions this usually raises
- How long are logs kept?
- Retention is a platform setting rather than a fixed promise on this page. Choose it deliberately, because it is also a data-protection decision.
- Can I export logs?
- Logs and filtering are console features, and the help centre covers what can be read and filtered rather than what can be exported.
- Does the log contain the text of messages?
- No. The message log stores metadata only, so your system stays the one place that holds message content.
Keep reading
Pacing, quotas and why we queue
Every connection carries a send rate. The platform queues to that rate instead of firing as fast as a provider will accept, because the fastest way to get throttled is to send at the speed that causes it.
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 →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 →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.