IP Allowlists for Backend API Credentials
Use IP restrictions as one access-control layer, account for proxies and outbound networks, and avoid treating a source IP as complete service identity.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
An IP allowlist can restrict where a credential is used. It complements authentication and scopes; it does not replace them or prove which application produced a request.
Identify the actual egress path
A backend may reach the API through a gateway, proxy or changing cloud egress address. Configure the observed authorised path rather than a developer laptop’s current address by habit. Keep loopback, private and public addressing rules distinct. Never trust a caller-controlled forwarded header as the network source without a defined trusted-proxy boundary.
Worked example: shared outbound address
Two internal services share one gateway IP. The allowlist admits both network paths, but only the intended service credential and scope should authorise access. A compromised neighbouring service must not gain access merely because it exits through the same address.
Test operational changes
Include a gateway change, an unauthorised network and a valid key outside the allowed path. Document emergency access and rotation procedures without broad permanent exceptions. Log safe denial reasons. A failed allowlist check should not trigger an automatic fallback to an unrestricted endpoint or another customer’s credential.
A practical acceptance test
Simulate two services sharing an authorised gateway and one request from an unauthorised egress address. Valid network origin alone must not authorise the wrong credential or project. Test caller-supplied forwarded headers outside the trusted-proxy boundary. A denied request should remain denied rather than automatically retry through an unrestricted endpoint or alternate customer key.
Questions about the topic
Frequently asked questions
Does an allowed IP identify one application?
Not necessarily. Several services can share an egress address.
Should IP restrictions replace API keys?
No. They are an additional boundary.
Standards & technical documentation
