IP Whitelisting for Client Proxy Credentials: A Practical Guide

Every sub-user credential you issue to a client is, by default, usable from anywhere by anyone who has it. That's fine until a credential leaks — checked into a public repo, pasted in the wrong Slack channel, reused by a client across more infrastructure than they told you about — at which point it's effectively free bandwidth for whoever has it, drawn from your stock. IP whitelisting is the direct fix: restrict a sub-user's credentials to only work from specific, known IP addresses.

When this matters most

• →Clients running from fixed infrastructure — a known server IP, a static office IP — where the legitimate usage source doesn't change
• →High-allocation sub-users, where a leaked credential is a meaningfully larger loss than a small one
• →Any client relationship where you want a clear, checkable record of exactly which IPs are authorized, rather than trusting the credential string alone as the only control

When it's the wrong tool

If a client's own usage pattern involves rotating source IPs on their end — running from cloud infrastructure that scales up and down, for instance — a tight whitelist becomes a maintenance burden that breaks their access every time their own IP changes. That's a case for relying on credential secrecy and rotation discipline instead of IP restriction, or for whitelisting a CIDR range if their infrastructure lives in one.

The three calls

• →`GET /api/v1/sub-users/:id/whitelist` — see what's currently authorized for a sub-user
• →`POST /api/v1/sub-users/:id/whitelist` — add an IP
• →`DELETE /api/v1/sub-users/:id/whitelist?ip=...` — remove one, e.g. when a client's infrastructure changes