A message record can show a numeric origin after your application supplied a brand name. When your application supplies text and from, Bird validates the requested sender and refuses an ineligible one. API acceptance does not guarantee the sender presentation on the handset. That validation does not replace the requested sender.
Does Bird ever swap my sender for a number?
For a message submitted with text and from, Bird refuses an unsupported sender without replacing it. A system-template request supplies a template reference from Bird's catalog instead of a custom message body. Bird selects the sender for that template request. The request and returned from field identify the sending form and sender used.
Bird checks the sender against the destination's policy before the message goes anywhere. If the destination does not carry the alphanumeric type, the call is refused. The call is also refused when the destination requires a registration that this sender does not hold. The error names the sender so you can read its requirements.
For a request with text and from, these checks refuse an ineligible send without rewriting the sender. A refused send produces no message, delivery attempt or delivery event. If a message exists with a different from, compare the original request, template selection and downstream route.
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.
In short
Bird refuses rather than substitutes.
Where a destination will not take an alphanumeric sender, the send is stopped at the API with an error. This admission check does not substitute a number for an ineligible free-text sender. Check the actual message and downstream route if the handset differs.
The refusal you get is
E12021, not the alpha-specific one.On a send, an unavailable sender type comes back as
E12021. The alphanumeric-specificE12018belongs to the registration path.One documented code is not emitted at all.
E12019is defined in the error catalog and nothing raises it. Branch on it and you will never take that branch.The
numericprogramme is not a substitution.In Bird's registration vocabulary
numericmeans registering a long code. It is a different sender type being registered, not your alphanumeric one being converted.