The production and sandbox APIs are IP restricted in addition to API key authentication. Your API key alone is not enough to reach them; the request also has to arrive from an address we have allowlisted.

​
Why a reverse proxy

We allowlist one egress IP per publisher. Game server fleets autoscale, move between regions, and get dynamic addresses, so allowlisting the fleet directly does not work for anyone. Route your SentinelID calls through a reverse proxy or a NAT gateway you control and give us its address. Most studios already have something suitable, whether that is an egress gateway, a service mesh, or a small proxy instance. This is server to server traffic only. Nothing about it touches the game client.

​
Getting allowlisted

Send the egress IP to casey@sentinel-id.com along with your publisher ID. Sandbox and production are allowlisted separately, so say which you need. Adding an address is a manual change on our side today, so allow a business day. Tell us in advance if you are migrating, and we will add the new address before you cut over rather than after.

​
What a rejection looks like

A request from an address we do not recognise returns 403 with a JSON body rather than an HTML error page, so you can tell it apart from an authentication failure:
The source_ip field is the address we actually saw. That is the value to send us, and it is usually the fastest way to spot that traffic is leaving through a different path than you expected. An invalid or revoked API key returns 401 instead. If you are getting 403, the problem is the network path, not the key.

​
Decide your failure behaviour before you ship

Your proxy will go down at some point, and so will ours. Decide now what your game server does when SentinelID is unreachable, because the default your integration falls into is rarely the one you would have chosen. Fail closed. Unverified players cannot join. Nobody plays during an outage, including legitimate players who have done nothing wrong. Appropriate for a ranked or competitive playlist where integrity matters more than availability. Fail open. Unverified players are allowed in and flagged. The game stays up, and for the duration of the outage you are running without the protection. This is usually the right default for casual or general population servers. What we recommend for most integrations: fail open with a short timeout, around two seconds, log every unverified admission, and reconcile afterwards. That keeps your game up during an outage while leaving you a record of exactly who joined without verification, which you can act on retrospectively. A ban issued an hour later still sticks to the device, which is the whole point of the product. Whichever you choose, make it explicit in your integration rather than an accident of how your HTTP client handles timeouts.

​
Latency

The extra hop through your proxy adds to the round trip. Our own verification budget is under 50ms server side, so keep the proxy close to the game servers rather than in another region, and use a persistent connection. A proxy on the other side of the world will dominate the total.