Wildcard route

The wildcard route is an exception to the rule that every message goes out from a sender registered in your account. It exists for one kind of account: wholesale providers that carry the traffic of third parties under their own customers' sender names — transit traffic, where registering every sender in advance isn't possible.

With the route enabled, a from that matches none of your senders is no longer refused with 422: it travels under your Wildcard Sender — in full, the Wildcard Sender (in transit): wildcard is how the dashboard names it, and in transit is how regulators refer to the traffic it carries. It is a sender with no alias of its own: the alias the recipient should see travels in each message, in your from.

Without the route, nothing changes for you: register your senders and send from them. If your traffic is your own brand's, that is the setup to use.

Accounts that were already sending through the wildcard route keep it.

Where the route shows in the dashboard

In the A2P Messaging API project, the SMS channel has a Settings tab, after Overview, Senders and Messages. Its Wildcard route block shows the route's status:

• Enabled — "Messages whose sender isn't registered in this project go out under your Wildcard Sender.", with a Manage registrations button.
• Not enabled — "Every message needs a sender registered in this project. The wildcard route, for wholesale providers, is available on request.", with a Request the wildcard route button.

The same status is on every other tab of the SMS channel, in the Wholesale providers section of the right-hand panel: a Wildcard route row with Manage or Request, next to the SMPP row.

Without the route, the senders table has no Wildcard route row. With it, the Wildcard Sender is listed there — in its sheet, the Wildcard Sender (in transit).

Requesting the wildcard route

The route is not available by default, and you never turn it on yourself: you request it from the dashboard.

1. 1

   Open the SMS settings

   In the A2P Messaging API project, go to the SMS channel's Settings tab and select Request the wildcard route (or Request in the Wholesale providers section).

2. 2

   Choose your wholesale legal profile

   Under Choose your wholesale legal profile, pick your company's legal profile, or create one. It is the profile the regulators will see as the provider carrying the traffic.

3. 3

   Send the request

   Confirm with Send request. Once the route is granted, you can't turn it off from the dashboard.

Today the route is granted at once, and the dashboard confirms it with "Request sent. Wildcard route enabled".

Requesting it needs permission to edit the project and the owner, admin or manager role in the organization.

What happens to transit traffic

Each regulated country decides how transit traffic is treated, and two things decide whether a message gets through:

• A transit registration for that country. In countries with an active regulator, such as Spain, the Wildcard Sender needs a registration for that country. From Manage registrations in the SMS Settings tab, tell us which countries to cover in transit; our team reviews each request against the regulator before activating it.
• Your company registered with that regulator as a provider, where the regulator requires it — see Spain below.

Without them, delivery is best-effort, along the lines set out in Coverage & delivery: we maximise the chances of the message arriving, without promising it will, and the recipient may see a different sender. In some countries there is no alternative at all, and a message the operator won't accept doesn't go out. Countries that need no registration take transit traffic as is.

Only a from can produce transit traffic: a message identified by sender id always uses that sender. And your destination countries apply to transit traffic like to any other.

Spain: your company has to be a registered provider

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.

To carry traffic into Spain under the Wildcard 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.

A numeric from doesn't qualify

The alias the regulators examine for transit traffic is the one in your from. A from made of digits never takes an alternative route: where an alphanumeric from would be carried best-effort, a numeric one is not.

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.

SMPP needs the wildcard route

SMPP traffic always carries your customer's own sender name in source_addr, so it relies on this route: SMPP keys can only be created when the account has both SMPP access and the wildcard route. How to request SMPP access is in SMPP authentication.

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 senders and countries you can, even with the route enabled: traffic riding the Wildcard Sender costs the same whether it arrives or not.

A message refused with 422 — for its destination country, for instance — is not sent and not charged.

RCS doesn't work this way

There is no wildcard route 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. See RCS agents.