IP whitelisting
Your servers' public IP addresses must be registered before any call will succeed. This is one of exactly two things that authenticate you (the other is your bearer token), which is why it is checked on every request and why there is no way around it.
The rule that surprises people
An empty allowlist denies everything. There is no "not configured means allow anyone" state. If no addresses are registered against your grant, every call is refused, including with a perfectly valid token.
This is deliberate. Allow-all is the one default this control must never acquire, because the cost of getting it wrong is that anyone holding a leaked token can use it from anywhere.
When you are refused, we tell you which address we saw
A refusal for this reason does not just say "not allowlisted": it tells you the source address we actually resolved for your request.
That single field is usually the whole answer, because the commonest cause is that your egress address is not the one you think it is. A load balancer, a NAT gateway, a cloud provider's egress pool or a proxy will all present an address that is nowhere in your server's own configuration. Compare what we report against what you registered, and the gap is your fix.
Registering addresses
Addresses are registered per grant, which means per short code and service, and arranged with the operator team. Send:
- Every public address your servers may call us from, including failover and secondary regions
- A CIDR range if you scale across a block, rather than a list you will have to keep amending
Ranges must actually narrow. We refuse an entry broad enough to be meaningless: 0.0.0.0/0 and
anything close to it. An allowlist entry that admits most of the internet is not an allowlist entry,
and accepting one would quietly turn this control into decoration while still appearing configured.
One allowlist, two surfaces
Every registered address carries a scope, and the scope decides which door it opens.
| Scope | Whose addresses | Opens |
|---|---|---|
| API | Yours. Every server that calls the SP API. | The endpoints in this documentation. |
| Header enrichment | The operator's, not yours. | The enrichment redirect a subscriber's browser follows. |
You only ever supply API-scope addresses. Header-enrichment entries are the operator network's egress ranges, which Tornet knows and you do not, so the operator team sets them when your service is configured for enrichment. Nothing you can register will open the enrichment surface, and that is by design: your servers do not call it, a subscriber's handset does.
The two do not substitute for each other. An address registered on one scope is invisible to the other gate, which produces the one symptom worth recognising:
This almost always means the entry is on the other scope. It is the failure that looks least like a configuration problem, because the portal shows the address present and correct.
If your API calls are refused, ask which scope your entry is on before re-sending the address. Sending it again produces a second entry on the same wrong scope.
Two things worth knowing
Changes are not instant from your side. Register new addresses before you cut over to new infrastructure, not during. A migration that changes your egress address without a matching registration fails every call at once, and it fails in a way that looks like an outage rather than a configuration change.
Checking it works
The safest test is the one on Getting started: a GET to subscription status. It changes nothing,
and a success proves your address, token, grant and capability all line up.