Sender ID registration is the step where you tell a destination country's registry, in advance, which identity you will be sending from and what you will be sending. Until that record exists and is approved, the country's answer to your traffic is no.
The word "registration" hides how specific the record is. It is not something your account has. It is something one sender has, in one country.
What does a registration actually record?
One sender, one destination country, and the state they are in together.
That pairing is the whole design, and it is visible in the read that reports it: each row of a sender's requirements carries a sender_id and a country_code, because "what a country needs is addressed by the sender and the country together". So the same alphanumeric string can be approved in one destination, pending review in a second and never registered in a third, with no contradiction.
Each row also carries where that pair stands. Bird's registration lifecycle has nine states, and the two that let a message through are approved and not_required. The rest are all forms of not yet: registration_required means nothing has been started, pending means work has begun, under_review and carrier_pending mean somebody else is holding it, bird_approved means our review passed and the carrier's has not, and rejected and suspended mean it was refused or withdrawn.
not_required is worth pausing on. It is a real answer, not a gap in the data. A country that asks for no registration is not an unregistered country; it is a country whose answer is already yes.
Which registration programme applies to my sender?
The destination decides, and it names the programme in its own policy record.
Bird's API publishes exactly five, and the names are the vocabulary the rest of the system uses. The right-hand column is the API's own gloss for each, quoted, because a programme's identity is a value the platform publishes rather than something to memorise:
| Programme | The API's gloss |
|---|---|
10dlc | "US A2P brand and campaign registration" |
tfn | "US toll-free verification" |
alpha | "registers an alphanumeric sender" |
numeric | "registers a long code" |
ctia_short_code | "a US short-code application" |
Read the two that name a country as the programme's own name rather than as a statement about where you can send. Which destinations run which programme is on SMS destinations, and a country can adopt or drop one without the programme changing what it is.
Two of them are not yours to drive from the ordinary registration call. A sender covered by 10dlc or tfn has its own flow, and asking the generic endpoint to register it returns a 422 pointing you at that flow instead: a long code is linked to a campaign, and a toll-free number is cleared by submitting a verification. Short-code registrations are ones Bird manages, and they return 422 for the same reason.
That leaves alpha and numeric as the two the sender registration call actually creates. Both go through the same endpoint and differ in what they cost you: registering a number is free, and a priced alphanumeric sender carries a setup fee and a recurring monthly charge.
The programme names are an open enum. Match the ones you handle and tolerate a value you do not recognize, rather than treating an unfamiliar programme as an error.
How do I find out what a country wants before I send?
Ask the sender, not the documentation. The answer is data, and it changes.
bird sms senders requirements <sender-id>Every row is a country this sender can reach. required says whether that country needs a registration first, program names which of the five runs it, status says where you stand, and next names the operation or the external step that moves it along. Two fields on the row give you an expectation rather than a promise: timeline_min_days and timeline_max_days, "the shortest and longest time approval usually takes, in business days", both null where the country publishes no estimate.
Those timelines are per country and they move, which is why they are read rather than written down. The same is true of every other per-country fact here: which sender types a destination carries, which programme each one runs, and how long it takes are published on that country's page under SMS destinations.
The SMS sender IDs guide covers the registration itself, and 10DLC registration covers the brand-campaign-number flow for the programme that has one.
What happens to a send while the registration is not approved?
It is refused at the API, and knowing that saves you looking in the wrong place.
Bird checks the sender before the message goes anywhere. Where a country demands a registration this sender does not hold, the send comes back with an error naming the sender so the recovery step can read that sender's requirements. Where the country does not carry the sender's type at all, or does not accept a sender from where yours comes from, it comes back as E12021, This sender is not available for the destination country.
The practical consequence: there is no message, no delivery attempt and no failure event. If you are searching an event stream for evidence of a registration problem you will find nothing, because nothing was sent.
That makes registration different in kind from carrier filtering, which happens after the handover and reaches you as a delivery failure. The two get confused because the underlying cause is often the same. Why are my SMS messages being filtered by carriers has that half, including why unregistered traffic a carrier drops never arrives labelled as unregistered.
What is left after the registration is approved?
One more switch, and it is yours rather than the country's.
A destination country has to be enabled for your workspace before anything reaches it. That is a workspace setting, checked before the sender is even considered, so a country can be fully registered and still refuse your messages because it is switched off. The refusal is E12020, and a change to the setting takes up to a minute to apply, so a send right after you enable a country can still be refused once.
So the full set of conditions for a message to leave is: the destination carries your sender type, your sender satisfies whatever that country's programme asks, and the destination is on for your workspace. The requirements read answers the first two per country and reports the third alongside them, in a field named destination_enabled, which is the fastest way to tell a registration problem from a settings problem.