Restrict access with an IP allowlist

Restrict Tango API requests to approved source IP addresses by enabling an IP allowlist for your platform.

An IP allowlist (a list of permitted network addresses) is an optional, platform-level control designed for enterprise customers with elevated security or compliance requirements. Tango checks the source IP before processing the API request. An IP allowlist does not replace Basic Auth, OAuth, or OAuth with DPoP: continue authenticating every request.

Before you begin

• Set up a server-side integration with Basic Auth or OAuth 2.0.
• Identify the public egress IP addresses (the addresses your requests use when leaving your network) for every system that calls Tango API, including proxies, middleware, and API gateways.
• Contact your Tango representative or [email protected] to coordinate platform-level enablement. The allowlist is disabled by default; your Tango representative enables it through a platform-level setting in Tango’s administrative system.

Enable an IP allowlist

1. Collect the source IPs Tango will see. Include all systems that send requests to Tango, not only your application servers. If a proxy or gateway sends the request, account for its egress IP. Tango evaluates the source IP at its edge.
2. Provide the approved entries to Tango. Send your Tango representative the individual IPv4 addresses or IPv4 CIDR ranges (a notation for a block of IP addresses) that should be permitted. Tango configures the allowlist for your platform; it applies to all Tango API endpoints for that platform.
3. Test in sandbox. Coordinate sandbox enablement with Tango, then send an authenticated request from an approved egress IP and confirm that it reaches the API. Check that a request from an address not on the allowlist is denied. Continue using your normal API credentials for both tests.
4. Verify coverage before production enablement. Check every caller’s egress IP, including proxies and middleware, against the entries you provided. Coordinate production activation with your Tango representative after the sandbox tests succeed. A missing egress IP blocks that caller even when its API credentials are valid.

Troubleshoot IP allowlist errors

If a request’s source IP does not match an allowlist entry, Tango rejects it before the API endpoint processes it. The authorization error indicates an IP restriction without revealing the approved addresses. Tango support and operations can use logs containing the source IP, platform, timestamp, and denial reason to investigate blocked requests.

• An approved caller is blocked: Confirm the public egress IP that reaches Tango, then check that it matches an allowlist entry. Inspect any proxy, middleware, or gateway between the caller and Tango.
• All callers are blocked after enablement: Check that the entries cover the actual egress IPs for your integrations. Contact your Tango representative to add or update entries.
• The IP is allowed but the API rejects authentication: Verify your Basic Auth credentials or OAuth token separately. Passing the network check does not authenticate the API request.

Maintain the allowlist

Before an egress IP changes or rotates, contact your Tango representative to update the entries so requests remain permitted. Review the list when you add a caller or change a proxy or gateway, and test changes in sandbox before production.

IP allowlist production checklist

Before enabling the allowlist in production, confirm that you have:

• Provided Tango with the public egress IP or IPv4 CIDR range for every caller, including proxies, middleware, and gateways.
• Tested an authenticated request from an approved IP and a blocked request from an unapproved IP in sandbox.
• Arranged with your Tango representative to update entries before any egress IP changes.
• Kept API credentials on every request; an approved IP alone does not authenticate your platform.

You can combine an IP allowlist with OAuth with DPoP and mutual TLS (mTLS). The allowlist restricts requests by source IP at the network layer, mTLS authenticates your client certificate at the transport layer, and DPoP binds an OAuth token to a client key at the application layer. Configure each control separately, and continue authenticating every API request.