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.
import { BirdClient } from "@messagebird/sdk";
const bird = new BirdClient({ apiKey: process.env.BIRD_API_KEY! });
const { data, error } = await bird.sms.send({
from: "Bird",
to: "+31612345678",
text: "Your order #4821 has shipped. Track it: bird.ly/t/4821x",
category: "transactional",
}).safe();
if (error) throw error;
console.log(data.id);
// → "sms_01m11jw130e7svjzv70kgqr38w"
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.
Submit the sender ID and the destination from the dashboard. Bird carries the registration to the local carriers or regulator on your behalf.
- 03
Track status through the API.
Approval runs through external registries and takes days to weeks. Poll the registration's state so your code waits for it before sending from that sender ID.
- 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.
Put it into practice.
Continue with the documentation, guides and examples for this topic. Resources are in English.
Other compliance topics
Sender-ID registration is one of three SMS compliance regimes. See the rest.
Register your sender ID, then send branded.
Sender-ID registration is one regime of SMS compliance on Bird. File from the dashboard, track approval through the API, and send from your brand name where it's allowed.