Short code, long code, toll-free or alphanumeric: which SMS sender type should I use?

Four sender types exist, and the question reads like a shortlist you work through. In practice most of the choice is made for you: the destination decides which types it carries at all, and one requirement of yours eliminates one of the four before you start.

What are the four sender types?

Bird's API names them long_code, short_code, alphanumeric and toll_free. That last one being separate is the part worth explaining, because plenty of writing treats it as a flavour of long code. The spec is explicit about why not:

The toll_free value is distinct from long_code. A country can permit one and refuse the other, and the two usually demand different registration.

The same reasoning appears on the sender resource itself: toll-free "is its own value rather than a kind of long code, because it carries a separate regulatory regime and both sending policy and pricing key on it directly".

Here is what each one is:

• Long code. An ordinary phone number, the same shape a person's handset has. It can send and receive, and it is the type most local numbers resolve to.
• Toll-free. A number from a toll-free range, which the industry treats as a separate regime with its own clearance step. CTIA's Messaging Principles and Best Practices puts it plainly: "Toll-free telephone numbers are a subset of NANP telephone numbers that use the following numbering plan area codes (NPAs): 800, 888, 877, 866, 855, and 844."
• Short code. A number several digits shorter than a phone number, built for volume. CTIA again: "Common short codes are non-NANP addresses of 5 or 6 digits typically used by businesses, entities, or organizations for high-volume communications with Consumers (e.g., airline flight delays, banking account alerts, shipping company delivery notifications, school delays)."
• Alphanumeric. A name rather than a number, capped at 11 characters, and send-only. What is an alphanumeric sender ID has the detail.

Both CTIA quotations are from its Messaging Principles and Best Practices, sections 5.5.6 and 5.5.4.

Which sender types can receive a reply?

The three that are numbers. Not the one that is a name.

This is the cleanest cut in the whole decision, and it is structural rather than a setting: a reply has to be addressed somewhere, and a name is not an address. So if any part of your programme depends on an inbound message, an alphanumeric sender is out. That includes the parts you may not think of as replies, such as a subscriber texting a stop keyword back at you.

Whether a given number can carry a two-way conversation to a given country is a separate, per-country question, reported as a direction of one_way or two_way on each sender type a country carries. One-way and two-way SMS covers how a reply reaches your application once you have a sender that can take one.

How do I choose without knowing every country's rules?

By reading them instead of learning them. A country publishes one entry per sender type it carries, and "a type absent from the list is one it does not carry", so the menu is a lookup rather than a memory exercise.

Each entry on that list carries what you actually need to compare:

• status, one of available, restricted, coming_soon or unavailable.
• registration_required, and the program that runs it when one applies.
• registration_timeline_min and registration_timeline_max, in business days, where the country publishes an estimate.
• throughput_mps, the send rate ceiling for that type.
• direction, one-way or two-way.
• allowed_source_countries, "the countries a sender of this type must belong to for this destination to accept it", empty meaning any.

Every one of those is per country and per type, and every one of them moves. They are rendered for each destination on SMS destinations, and returned for one of your own senders by:

bird sms senders requirements <sender-id> --country-code NL

That last field, allowed_source_countries, is the one people meet by accident. Where a destination sets it, a number from outside the list "has no route to this destination and nothing it can register for", which is how a programme that admits only local numbers is expressed. It is not a registration you are missing; it is a corridor that does not exist for a number of that origin.

What decides which sender Bird actually uses?

Routing priority, when you have not named one.

Every sender-type entry carries a default_routing_priority, an integer where lower means higher priority, and the destination page lists a country's types best route first. So the answer to "which should I use" often is the one already at the top of that country's list, and the question worth asking is whether you have a reason to override it.

Two things the priority does not decide. It does not enable a destination, which is a workspace setting of yours and refuses a send with E12020 when it is off. And it does not register anything: a higher-priority type you have not registered for is not a route you have.

What should I actually do?

1. Start from the destinations you send to, not from the sender types. Open the countries that matter on SMS destinations and read which types each one carries.
2. Rule out alphanumeric if you need inbound, including stop keywords handled for you.
3. Compare the registration cost and clock across the types a country does carry, rather than picking the type first and discovering the programme after.
4. Check throughput against your peak, since the ceiling is per type and per country.
5. Register, then verify. Approval is one of three conditions; sender ID registration covers the other two.

For the broader framing of why business traffic is governed at all, what does SMS mean covers application-to-person messaging. Each type also has a product page with the Bird specifics: long codes, short codes, toll-free and alphanumeric.