# Senders & coverage The `from` field is a sender, and some countries require it to be registered before an operator accepts it. This page covers what changes for an API integration: the Fallback Sender that carries unregistered traffic, the CNMC provider requirement, and what is billed. **Language:** en **Audience:** developer **TLDR:** Register the senders you send from — that is the short version. Traffic whose `from` matches no registered sender of the project travels under the project's Fallback Sender, which in some countries means best-effort delivery and in others means the message does not go out. Spain additionally requires your company to be a provider (PRO) registered with the CNMC, and their registry is the authority. Blocked transit messages are billed; blocked messages from a registered sender of your own are not. **Search keywords:** from field, sender id, unregistered sender, fallback sender, wildcard sender, wildcard route, in transit sender, transit traffic, sender registration api, cnmc provider registry, blocked and charged, numeric sender, alias spelling, exact alias, case sensitive sender, opt out substitution, country requirements json, coverage api **Related pages:** /developers/transactional-api/http/quickstart, /platform/en/channels/sms/coverage-and-delivery, /platform/en/channels/countries **Docs index (every page):** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt **This zone's index:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/developers/transactional-api/llms-full.txt **This page:** https://staging-instasent-docs-nextjs.oscar-284.workers.dev/developers/transactional-api/senders/ (HTML) · https://staging-instasent-docs-nextjs.oscar-284.workers.dev/developers/transactional-api/senders.md (Markdown) 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: - [Coverage & delivery](/platform/en/channels/sms/coverage-and-delivery) - What happens when you send to a country that requires registration and yours isn't approved yet. - [Countries](/platform/en/channels/countries) - Every destination, with what it asks for on each channel. > **Note**: **Machine-readable** — Those same per-country rules are published as JSON, so your > integration can read them instead of carrying a hardcoded country list: > > ```text > https://staging-instasent-docs-nextjs.oscar-284.workers.dev/data/country-requirements/{iso2}.json > ``` > > Swap `{iso2}` for the destination's two-letter ISO 3166-1 code, lowercase, or fetch > [the full index](https://staging-instasent-docs-nextjs.oscar-284.workers.dev/data/country-requirements.json) to get every country in one > request. It needs no key and no authentication, it allows cross-origin requests, and its > shape is described by a [JSON Schema](https://staging-instasent-docs-nextjs.oscar-284.workers.dev/data/country-requirements.schema.json). ## 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](/platform/en/channels/sms/coverage-and-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](#a-numeric-from-doesnt-qualify). > **Note**: Your reports, exports, DLRs and webhooks always show the `from` **you sent**. Where a > provider substitutes the sender, it does so on its side — what changes is what > reaches the handset, never what your integration reads back. ## 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. > **Warning**: If you route Spanish traffic through the API and your company isn't registered with > the CNMC as a provider, sort that out before the traffic matters. It is a filing with > the regulator, not a setting in the dashboard. ## 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](#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](/developers/transactional-api/http/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. --- This is one page of the Instasent documentation. For the complete machine-readable index of every guide and API reference, fetch https://staging-instasent-docs-nextjs.oscar-284.workers.dev/llms.txt — start there for full context.