Feature · Identity

Sender identity stays attached to your accounts

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.

What a sender identity can be

Which of these you can use depends on the destination country and on your provider. The platform sends from the identity you already hold on the connected account, so it travels with you.

  • Long codes — a standard number, the easiest to obtain and the most heavily rate-limited
  • Short codes — higher throughput, carrier approval required
  • Alphanumeric sender IDs — a name instead of a number, supported in some countries only
  • Toll-free numbers — where the country supports them

Registration is yours, and it is worth doing early

Many destinations require the sender to be registered and verified before traffic is accepted — 10DLC and short-code programmes being the best-known examples. Those registrations are filed by you, with your provider or the relevant authority, which is also why they sit in your name and stay with you.

  • Registration and verification are filed by you, with your provider or the relevant authority
  • Nothing in the middle can raise a provider quota or lift a carrier filter
  • An unregistered sender is rejected by the destination network, so registering early is part of going live

Choosing between numbers

When a country supports several identity types, throughput and deliverability differ. The practical guidance — when a short code is worth the approval process, and when a second long code is enough — is in the sender selection guide.

Questions this usually raises

Do you provide numbers?
No. Sender identities belong to the provider account you connect, and the platform sends from the identity already on that account.
Will you file a 10DLC registration for us?
No — registration and verification are filed by you, in your own name with your provider or the relevant authority.
Why does one number send slower than another?
Different identity types carry different throughput limits. Long codes are the most limited, which is usually why a second number is added rather than a higher plan bought.

Keep reading

3 min

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 →
5 min

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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 →
Features

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.