API keys done right: IP allowlists, request logs, and the habits that keep access safe

An API key is a password that never sleeps. It lets your own systems talk to your affiliate platform without a browser — pulling reports, reading offers and partners, creating affiliates from your signup flow — and it does so unattended, at any hour, from any server you point at it. That power is exactly why the boring parts of key management deserve real attention. A leaked key is not a locked-out login; it is a live credential in someone else's hands. This guide is about the habits and controls that make programmatic access safe: least-privilege scoping, IP allowlists, a request log you actually read, and rotation that is painless enough that you'll do it. Before any of that, if you are wiring your first integration, the API getting-started guide covers the endpoints themselves.

Least privilege: keys should do the least they need

The first principle of any credential is that it should be able to do only what its job requires. A key that pulls reports every morning has no business being able to create records. Good platforms make read access — reports and entities — the baseline, and gate write capabilities like creating affiliates behind an explicit opt-in that is off by default. When you mint a key, you decide what this particular integration is allowed to do, and you grant nothing more.

This is not pedantry. The blast radius of a leaked key is bounded by what the key can do. A read-only reporting key that leaks is an information problem; a full-write key that leaks is a data-integrity emergency. Scoping keys tightly means that even in the worst case, the damage is contained to the one capability that key was given.

Shown once, stored properly

A well-designed platform shows you a new key's full secret exactly once, at creation, and never again. This feels inconvenient the first time it catches you, and it is precisely the right behavior: a secret the platform can redisplay is a secret the platform is storing in a form that could be read, and a secret that can be read is a secret that can leak. The discipline it forces on you — copy the key into a secrets manager immediately — is the discipline you wanted anyway.

The corollary is that losing a key is not a recovery problem, it is a rotation problem: you don't retrieve it, you revoke it and create a new one. Which is fine, because a healthy setup makes that cheap.

IP allowlists: pin the key to your servers

The single highest-leverage hardening step for a key with a stable caller is an IP allowlist. If your integration always calls from the same server or the same range, tell the key that. With an allowlist in place, a request from any other address is rejected and logged — which means a key that leaks is useless to anyone who isn't calling from your infrastructure. A stolen credential is worthless if it can only be used from an address the thief doesn't control.

Allowlists take individual addresses or CIDR ranges, so you can pin a key to one server or a whole subnet as your architecture requires. An empty allowlist means any address may use the key, which is the right default only when your caller's address genuinely isn't stable — a rotating cloud function, say. Whenever you can pin, pin.

The request log: your early-warning system

Every call made with your keys should be recorded — the successful ones and, more importantly, the failed ones. A request log that shows the time, the key used, the request, the outcome, the caller's IP, and the duration is not just for debugging; it is your intrusion-detection system. The pattern to watch for is a burst of authentication or authorization failures from an address you don't recognize, which usually means a key has leaked and someone is probing with it. The response is immediate and simple: revoke that key and issue a new one.

The log also resolves the everyday puzzles. A rejection from your own new server almost always means you stood the server up but forgot to add its address to the key's allowlist — the log tells you that in one line instead of an afternoon of guessing. This is the programmatic-access sibling of the account activity log: same instinct — record everything that matters so "what happened?" is a lookup, not an investigation.

Expiry and rotation: make revoking cheap

Two habits turn key management from a source of anxiety into a routine. The first is setting an expiry on keys for anything temporary — a trial, a one-off migration, a contractor's project — so the credential cleans itself up if you forget it. The second is rotation: because you can hold several keys at once, replacing one is a zero-downtime operation. Create the replacement, switch your integration over, confirm it works, then revoke the old key. Nothing breaks, and the old credential is dead.

Rotation only feels scary when a system depends on a single irreplaceable key. When your platform supports several keys and one-key-per-system hygiene, rotation becomes something you do on a schedule without a second thought — which is exactly the state you want to be in when a key does eventually leak.

One key per system

The habit that makes everything above work is granting one key per integration rather than sharing a single key everywhere. When the reporting job, the signup flow, and the third-party automation each have their own key, you can revoke any one of them without breaking the others. Shared keys create the opposite situation: the credential leaks, and revoking it takes down three systems at once, so you hesitate — which is exactly when a leaked key does the most damage. Per-system keys remove that hesitation.

They also make the request log far more useful, because you can tell which integration made a given call. A shared key turns the log into an anonymous blur; per-system keys turn it into a clear account of who did what.

Who can manage keys

Because API keys are powerful, the ability to create, view, and revoke them should be an administrator privilege — not something every staff member or partner can reach. This fits the broader access model of a well-run account, where sensitive configuration is gated to the people responsible for it. How those roles are defined and assigned is covered in the team and roles guide, and it is worth aligning your key-management access with the same least-privilege thinking you apply to the keys themselves.

The safety rules, in one place

Everything above condenses into a short list worth keeping:

• Keys belong on servers, never in browsers, mobile apps, or public repositories. A key in client-side code or a committed file is already compromised.
• One key per system, so revoking one integration never breaks another.
• Use an IP allowlist whenever your caller has a stable address — it is the cheapest, strongest control you have.
• Set an expiry on anything temporary, so forgotten keys expire themselves.
• Watch the request log for unexpected denials, and treat a burst from an unknown address as a leak until proven otherwise.

What keys unlock

It is worth remembering what all this hygiene is protecting, because it explains why the effort is proportionate. An API key is not a minor convenience; it is the door through which your affiliate data flows into the rest of your business. A reporting key feeds your dashboards and your board decks. A signup-flow key turns your own onboarding into affiliate records automatically. An automation key lets a workflow tool react to conversions in real time. Each of those integrations is doing real work, and each depends on a credential that, if mishandled, exposes the data behind it. The keys are valuable precisely because what they reach is valuable.

That framing is what makes the discipline feel worth it rather than bureaucratic. You scope tightly, pin to your servers, and watch the log not because a checklist told you to, but because the key sits between a stranger and your program's data. Treating it with the seriousness that position deserves is simply matching the control to the stakes — and once the habits are in place, they cost almost nothing to maintain.

None of this is exotic. It is the same credential hygiene that protects any serious system, applied to the keys that drive your affiliate data. Done consistently, it means a leaked key is a five-minute rotation rather than a breach. If you want to see programmatic access, IP-pinned keys, and a live request log in one place — and drive every platform capability from your own tools — the MCP and API feature overview shows the surface, and a demo will wire a scoped, allowlisted key on a real workspace with you.