Senders and country coverage

The from field you send is a sender — the name or number the recipient sees. It works the same through this API as it does in the dashboard, and the rules that govern it are the same ones: some countries accept any alphanumeric sender, some replace it with a number, and some require it to be registered before an operator will accept it as yours.

Those per-country rules are documented once, for both surfaces:

Register the senders you send from

That is the short version of this whole page. Register each sender for the countries you send to, and your messages arrive under your brand, predictably, with nothing else to think about. On RCS it isn't a recommendation but a requirement: an agent has to be registered per country before anything is sent there.

Everything below describes what happens when you haven't — which is worth knowing, but is not the state to operate in.

Traffic with no registered sender

In the dashboard you pick a sender you created. Through the API you put any string in from, and it may not correspond to any sender registered for your project.

That traffic isn't rejected. It travels under the project's Fallback Sender — in full, the Wildcard (In transit) Sender, which is how you'll see it named in the dashboard and how the regulator refers to the traffic it carries. It is a sender with no alias of its own, and it exists precisely to carry whatever doesn't match a registered one. You don't create it: the project has at most one, and it is set up for you.

In some countries that means best-effort delivery, along the lines set out in Coverage & delivery: we look for the best available route so the message still arrives, without promising it will. In others there is no alternative route at all, and a message that the operator won't accept simply doesn't go out.

Which of the two applies depends on the destination and on how your request is formed — and one condition matters more here than anywhere else, because it only exists for API traffic: see A numeric from doesn't qualify.

Spain: you have to be a PRO, registered as such with the CNMC

This is the requirement most likely to catch an integration out, because it is met outside Instasent and nothing in your code will tell you it is missing. It is also the reason this page exists rather than a link: it applies to wholesale traffic, so the product documentation — written for end customers — doesn't cover it.

To carry traffic into Spain under the Fallback Sender, your company has to be a provider (PRO) and be registered as one with the CNMC. We supply the identifier you filed with them — taken from your legal profile, or from your organisation's details — and the CNMC's own registry is what decides: if your company isn't listed and active there, the message doesn't go out.

The authority is their registry, not any status in our system. A registration can look fine on our side and still be refused because the provider check fails.

Send the alias exactly as you filed it

Where a sender is filed with a regulator, the check against that registry is literal — character by character, capitals included. Nothing is normalised on the way.

If you filed PEDRO and your request carries Pedro, that check reads your alias as not filed, with all the consequences of not being filed — even though the procedure went through and was approved.

It is worth a line in your integration, because it is the hardest failure to diagnose from the outside: the register shows as approved, the regulator has your alias, and the messages still don't arrive as they should. If you build from from a database field or a template, make sure it reproduces the filed spelling.

A numeric from doesn't qualify

The Fallback Sender has no alias of its own — the alias travels in the message, in your from. And that is what is examined when a message needs an alternative route.

A from made of digits never takes an alternative route. Where an alphanumeric from would be carried best-effort, a numeric one is not. This only affects API traffic, because in the dashboard the sender is always one you created.

That splits into two very different cases, and the difference is whether what you sent is a real phone number:

• A valid international phone number doesn't need an alternative route in Spain: it is exempt from the CNMC and accepted without any filing.
• A string of digits that isn't a phone number — 123, an internal code, a short reference — is neither exempt nor carried: it has no route and no exemption, so it doesn't go out.

If you send numeric senders, send real phone numbers.

Choosing blocking over substitution

Some senders would rather not go out at all than go out with the recipient seeing a different sender — a brand where the name is the point, or traffic where an unexpected sender would raise a support case of its own.

The sender carries a field for that: unregisteredBypassRouteOptOut. With it on, in a country whose regulator is in force, that sender never takes an alternative route — the block applies as it stands, and the message is reported as blocked by regulation.

Two limits worth knowing before you set it:

• It changes nothing where there is no regulator, and nothing before a regulator's rules take effect. It isn't a global "never substitute my sender" switch.
• It doesn't change what is billed. Transit traffic blocked this way is billed just the same; a specific sender of your own, blocked, is not — the same asymmetry as in What is billed.

It lives on the sender, not on the account, on purpose: a Fallback Sender covers all of a reseller's unregistered traffic, so the choice belongs with the sender that carries it.

What is billed

A blocked transit message is billed. A blocked message sent from a registered sender of your own is not.

That asymmetry is deliberate, and it is the most concrete reason to register the countries you send to: traffic riding the Fallback Sender costs you the same whether it arrives or not.

Delivery reports tell you the outcome per message — see DLRs.

RCS doesn't work this way

There is no equivalent on RCS, and there won't be. An RCS agent is always tied to a known provider, so there is no sender without an alias for traffic to travel under: the agent has to be registered for each country before anything is sent there.