The Sender ID Is Optional Until It Is Not
Three SMS providers, one missing sender name, three different behaviours: one omits the field, one substitutes a default, one refuses to send at all. None of them is wrong, and a connector that assumed any one of them would break on the other two.
The name a text message appears to come from is a small field with a surprising amount of regulation behind it. In some markets you can put anything in it. In others it must be registered in advance, with a company registration and a fee, and an unregistered one is silently replaced or the message is dropped. What the three providers here do when you have not got one yet is genuinely three different things.
Three answers to one absence
| Provider | With no sender configured | What you get |
|---|---|---|
| Africa's Talking | The field is left out of the request entirely | Their default sender — usually a shared shortcode |
| Infobip | A default value is substituted | That name, if the account permits it |
| Twilio | The send is refused before it leaves | A message naming the missing field |
Each of those is correct for its provider. The first has a working default and accepts requests without the field. The second wants something. The third genuinely cannot send without one, because on that platform the sender is the account's own number and there is nothing to fall back to.
One shared way of handling a missing field across three providers would be wrong on two of them, and the wrongness would surface as a rejected message rather than as a mistake.
Omitted is not the same as empty
The first row hides a distinction that is easy to get wrong and produces a puzzling failure.
Leaving the field out of the request and including it with an empty value are two different requests. The first says use your default. The second says use this sender, whose name is nothing, which is not a valid sender and is refused.
So the connector builds the request without the field and adds it only when there is something to add. That is a single conditional, and it is the difference between a connector that works out of the box for somebody who has not registered a sender name yet, and one that fails on the first message with an error about a field they never filled in.
The general form of this is worth carrying elsewhere: an absent key and a key with an empty value are different statements, and APIs routinely treat them differently. Building a payload by including everything and letting the empties through is the version that looks tidier and behaves worse.
Why the sender name is in the failure message
When a send fails without a usable reason from the provider, the message this connector reports names two things: the credentials and the sender identity.
That is not padding. Those are the two overwhelmingly likely causes, and the sender identity is the one people do not think of — because it was set up once, months ago, by somebody else, and it looks like a display preference rather than something that can be rejected.
A sender name can stop working for reasons that have nothing to do with your integration: a registration lapses, a market tightens its rules, an operator starts filtering unregistered senders. The message that arrives has nothing to do with the code, and pointing at the field is worth more than a generic failure.
What actually to put in it
The rules are per-market and per-operator rather than per-provider, which is why no connector can validate this for you. Three broad shapes exist and each behaves differently.
-
An alphanumeric name
Your company name in the sender field. Recognisable, and in most markets it must be registered in advance. It also usually means the recipient cannot reply, since there is no number to reply to.
-
A shortcode
A few digits, leased and registered. Two-way capable and the usual choice where replies matter or where alphanumeric senders are restricted.
-
The provider's shared default
What you get when you configure nothing. Fine for getting started and for internal alerts; it does not identify you, and it is shared with everybody else using it.
For alerts going to your own staff, the third is genuinely adequate — the people receiving them know what the message is about, and the content identifies it. For anything a person outside the organisation will read, the registration is worth doing, and it is worth starting early because it is an administrative process rather than a technical one.
One field, three homes
A last structural note that explains why these three connectors sit behind one settings screen.
All three store their credentials in the same three fields, and the fields mean different things per provider. What one calls a username another uses for an account identifier and a third uses for a web address. The connector routes to the right driver by which provider you chose, and each driver reads the same three fields with its own meanings.
That keeps one settings screen rather than three, and it is the reason the labels on that screen change when you change the provider — the field is the same and what belongs in it is not.
What is in place, layer by layer
Sender identity across the three SMS providers
A field omitted rather than blanked
Where a provider has a working default, the sender field is left out of the request entirely, because sending it empty is a different and invalid request.
A default substituted where one is wanted
Where a provider expects a value, one is supplied rather than sending nothing and receiving a validation error.
A refusal where the field is genuinely required
Where a provider cannot send without it, the connector says so before making a request, naming the missing field.
The sender named in the failure text
Where a failure has no usable provider reason, the reported message names credentials and sender identity — the two likely causes, one of which nobody thinks of.
One settings screen, three providers
A shared configuration with per-provider meanings and per-provider labels, so choosing a provider changes what the fields ask for.
Your own account throughout
Whichever provider you choose, the credentials, the credit and the registered sender are yours.
Credentials encrypted at rest
Stored on the row for one workspace, and never written into a log line or shown back in an error.
What may go in the sender field is decided by market and operator rules rather than by any provider, which is why no connector can validate it for you and why the registration is worth starting before you need it.
Three positions held on purpose
- Each provider is handled as it behaves rather than through one shared rule. A single policy for a missing sender would be right on one of the three and would fail on the others as a rejected message rather than as an obvious mistake.
- A key is omitted rather than sent empty where that is what the provider wants. The two are different requests, and the version that includes everything and lets empties through is the one that looks tidier and breaks.
- The likely cause is named in the failure rather than described generically. A sender registration that lapsed is invisible from the code and obvious from the field, and pointing at it saves the wrong investigation.
Five questions about sender identity
Can we start without a registered sender?
A good answer sounds like
On some providers, yes.
What ours actually is
Where the provider has a working default the field is omitted and messages go under theirs.
What if the field is left empty?
A good answer sounds like
It is omitted, not sent blank.
What ours actually is
An empty value is a different and invalid request. The key is left out instead.
Why did sending suddenly stop?
A good answer sounds like
Check the sender first.
What ours actually is
The reported failure names it, because a lapsed registration is invisible from the code.
Do all three providers behave the same?
A good answer sounds like
No, and here is how.
What ours actually is
One omits, one substitutes a default, one refuses. Each is handled the way it actually works.
Can you validate our sender name?
A good answer sounds like
No, honestly.
What ours actually is
The rules are per market and per operator. No connector can check them, and pretending to would be worse.
Our take
The fields that cause the most trouble in an integration are rarely the complicated ones. They are the small ones with regulation behind them — a sender name, a tax identifier, a currency code — where the technical requirement is trivially satisfied and the real requirement lives in a registry somewhere that nobody in the room has access to. The engineering answer is to make the field easy to leave alone, honest about what happens when you do, and specific about it when things go wrong. The rest is an administrative process, and the useful thing a product can do is start you on it early rather than at the point of failure.
Start the sender registration before you need it
It is paperwork rather than engineering, it takes as long as it takes, and it is the field that stops messages arriving in a market that tightens its rules.
Talk through SMS alertsFrequently asked questions
Can we send text messages without registering a sender name?
On the provider whose default works, yes — the field is left out and messages go under theirs. That is genuinely fine for alerts to your own staff. For anything read by somebody outside the organisation, a registered sender is worth having, and the registration is administrative rather than technical.
Why do the settings labels change when we switch provider?
Because the three providers store their credentials in the same three fields and mean different things by them — what one uses for a username another uses for an account identifier and a third for a web address. The labels follow the provider so the screen asks for the right thing.
Our messages stopped arriving and nothing changed on our side. Why?
The sender identity is the first thing to check. A registration can lapse, a market can tighten its rules, and an operator can start filtering unregistered senders — none of which is visible from the integration. That is why it is named in the failure text.
Can recipients reply to these messages?
That depends on the sender you use rather than on the connector. An alphanumeric name usually cannot receive replies because there is no number behind it; a shortcode can. Either way this connector sends and does not read, so a reply would go to your provider account rather than into your workspace.
Which provider should we pick?
Mostly a commercial and coverage question rather than a technical one — pricing and delivery quality in the markets you actually send to. All three are handled as they behave, so the choice is about your provider relationship rather than about which one the integration prefers.
