You sent from a brand name and the handset showed digits. It is a common enough experience to have become folklore, usually explained as "some countries replace the sender". That is a real behaviour in the industry, but it is worth establishing first what Bird does, because on Bird the answer is not substitution.
Does Bird ever swap my sender for a number?
No. Where an alphanumeric sender cannot make a send, the send does not happen.
Bird checks the sender against the destination's policy before the message goes anywhere. If that destination does not carry the alphanumeric sender type, or does not accept a sender of that type from where yours originates, the call is refused. If the destination carries the type but wants a registration this sender does not hold, the call is refused with an error that names the sender so you can read its requirements.
Either way there is a refusal rather than a rewrite, and the practical difference matters when you go looking for evidence. A refused send produces no message, no delivery attempt and no delivery event. A substituted one would have produced a delivered message with a different from field. If your logs hold the second, the change did not come from Bird's send path.
Which refusal will I actually see?
Three codes get quoted for this and they are not interchangeable.
| Code | Where it comes from |
|---|---|
E12021 | The send path, when the destination does not carry your sender's type or your sender's origin |
E12018 | The registration path, when you try to register an alphanumeric sender for a country that does not carry the type |
E12019 | Defined in the catalog and raised by nothing |
The first two are the pair to know. E12021 reads This sender is not available for the destination country and is what a send returns; E12018 reads Alphanumeric senders are not available for the destination country and is what registering returns. They describe the same country policy from two different doors, which is why searching for the alphanumeric-specific wording after a failed send finds nothing.
The third is a trap of the same shape the carrier filtering page describes for delivery codes. E12019 is published, documented, and emitted by no code path. A registration that is required but missing surfaces as an error naming the sender, not as E12019. Handle it if you like, but do not treat its absence from your logs as evidence that registration is fine.
Is the numeric registration programme what happened to me?
No, and the name invites the confusion.
Bird's registration programmes include one called numeric, and read cold it sounds like the thing that turned your name into digits. It is not. numeric registers a long code: it is the programme a country runs for the number sender type, applied to a number you already hold. Nothing in it converts an alphanumeric sender into a numeric one.
If a country you send to runs numeric, what that tells you is that its long codes need registering, which is useful when you are choosing a sender type but says nothing about your alphanumeric one. Sender ID registration has all five programmes and which sender type each applies to.
So where did the number come from?
Somewhere other than the sender-type gate, and there are three places worth checking in order.
- Read back what you actually sent from. The message record carries its own sender, and a workspace with several senders configured is the ordinary way a send goes out from a different one than you meant. Filter your messages by sender to see which identity carried it.
- Check whether the message came from Bird at all. If the same programme also sends through another provider, or through a fallback in your own code, the number may be that path's default sender rather than a rewritten one.
- Ask about the specific message. Once a message left Bird it passed through a carrier, and what a network does with a sender after the handover is that network's behaviour rather than a setting you hold. Quote the message id to support, along with the destination and the sender you expected.
Two things do not explain it, and ruling them out saves time. It is not your registration being pending, because a pending registration refuses the send rather than downgrading it. And it is not the destination being switched off for your workspace, because that refuses the send too, with E12020.
What stops it happening again?
Decide the sender per destination rather than per campaign.
The durable fix is to know, before you send, which sender types each destination carries and what each one requires. That is published per country on SMS destinations, and it is answerable for one of your own senders from a terminal:
bird sms senders requirements <sender-id>Where a destination does not carry the alphanumeric type at all, no registration exists to buy your way in, and the choice is a different sender type. Which sender type should I use compares the four. Where it does carry the type and wants a registration first, SMS sender IDs covers making one.