Send from your
name, where it's
allowed.
An alphanumeric sender ID puts your brand name in the from field instead of a number. Many countries require you to pre-register that name before it can deliver. Bird files the registration and reports its status through the API so you know when the sender is live.
Your brand. The destination’s requirements.
Sender identity
FIELDNOTES
Claim
Create the brand sender in the workspace.
Country requirements
Read required registration and next actions.
Ready to send
Check approval and an enabled destination.
Illustrative sender workflow. Read each country’s current requirements before sending.
Why some senders need registering first.
Sender-ID registration is part of SMS compliance on the Bird SMS API. To curb spoofing, a number of countries only deliver alphanumeric sender IDs that have been pre-registered with the local carriers or regulator. Where that applies, an unregistered branded sender is rejected or rewritten. Bird files the registration for you and exposes its state, so you don't send into a sender that can't deliver yet.
How registration works.
Where it's required, who files it, and when it's live.
- 01
Know where it's required.
Whether an alphanumeric sender ID needs registering depends on the destination country. Some require pre-registration, some allow dynamic senders, and some don't permit alphanumeric at all.
- 02
Bird files it for you.
Choose the sender and destination, read the requirements and submit the registration through its supported workflow. Complete any additional form the program requests.
- 03
Track status through the API.
Review the destination’s published requirements and any available timeline. Read the registration status and resolve requested corrections before sending.
- 04
It applies to alphanumeric senders.
Registration governs the alphanumeric sender ID itself. Sending from numbers — long codes, short codes, toll-free — follows the rules of those number types instead.
Check a registration's status from the API.
You file the sender ID from the dashboard; the requirements read tells you where it stands, one row per destination country. Branch on that row's status, and on whether the destination is switched on, before you send from that sender.
// The sender surface is not on the SDK yet, so read it over HTTP with a key
// carrying the sms_management:read scope.
const res = await fetch(
`https://eu1.platform.bird.com/v1/sms/senders/${senderId}/requirements`,
{ headers: { Authorization: `Bearer ${process.env.BIRD_API_KEY!}` } },
);
const { data: countries } = await res.json();
// Registration is decided per destination, so there is one row per country
// this sender can reach — never a single status for the sender itself.
const india = countries.find((c) => c.country_code === "IN");
// approved and not_required are the two statuses that satisfy a country.
// destination_enabled is a separate axis: a fully registered country still
// refuses the send while the workspace has it switched off.
if (india.status === "approved" && india.destination_enabled) {
// safe to send from this sender ID to India
}
Registration follows the alphanumeric sender.
This is the compliance step behind alphanumeric sender IDs. The sender type lets you send from a brand name where the country allows it; registration is what makes that name deliverable where the country requires it first.
Questions about registration and sending
Is claiming a sender ID the same as registering it?
What should I check before sending?
How long does registration take?
Other compliance topics
Sender-ID registration is one of three SMS compliance regimes. See the rest.
Scale without
losing control.
Organize teams in workspaces, control API access, and trace changes through audit logs.
Audit log
Production- Workspace
- Production
- Resource
- Delivery agent
- ReadRead & write