Partner API Access & API Keys
When other businesses integrate with us through code, we expose APIs and give them credentials. Each partner key is a powerful, long-lived secret that grants access to our data. So how we issue, scope, rotate, and revoke these credentials, and how we isolate and limit partners, is a core part of keeping the platform safe.
Partner and machine access is different from human login. It is often a long-lived API key or client credential used by another system, with no MFA and no human watching. So scoping and lifecycle management are critical: a leaked or over-privileged partner key can expose a lot. Prefer standard machine auth (OAuth client-credentials via the IdP) over custom API keys where you can (see Identity Provider & SSO).
Treat each partner as a tenant boundary and an untrusted caller. They see only their own data, they are rate-limited and have quotas, and their access can be turned off instantly.
Issue and manage credentials well
- DoPrefer OAuth 2.0 client-credentials (via the IdP) for partner and machine access. If you must use API keys, treat them as secrets: hashed at rest, shown once, never logged.
- DoScope each credential to the least it needs (which data, which operations, which partner or tenant). No broad, all-access keys.
- DoSupport rotation, instant revocation, and expiry, so a compromised or retired partner credential can be disabled quickly (see Session & Token Management).
- DoAttribute and audit partner calls (which partner did what, and when) for security and support (see Audit Trails).
- NeverIssue a shared, long-lived, all-powerful key, or send or store a partner secret in plaintext. Share it through a secure channel and store only a hash.
Isolate and limit partners
- AlwaysEnforce that a partner can only access its own data. Derive the tenant or partner from the validated credential, never from a request parameter (see Multi-Tenancy).
- DoApply rate limits and quotas per partner so one partner cannot overload the platform or run up cost (see Rate Limiting & Abuse Prevention, Cost & Scale Planning).
- DoVersion the partner API and evolve it additively with a deprecation policy. You cannot break external consumers without notice (see Backward Compatibility, API & Contract Design).
- ConsiderA sandbox or test environment with separate credentials, so partners can integrate without touching production data (see Test Data & Environments).
- DoOnboard partners through the vendor and data-sharing governance process (agreements, lawful basis) (see Vendor & Third-Party Risk).
// one API key for all partners, full access, stored in plaintext
var partnerId = request.Query["partnerId"]; // caller picks!
A single leaked key exposes everything. And if the caller names the partner, any partner can read any other partner's data. No isolation, no rotation, no audit.
// OAuth client-credentials; token carries partnerId + scopes
var partnerId = ctx.PartnerId; // from validated token
// queries filtered to partnerId; per-partner rate limit; revocable
Each partner has its own scoped, revocable credential. Identity comes from the token. Data is isolated, and access is limited and audited.
Self-review checklist
- AskIs partner identity derived from a validated credential, and access limited to their own data?
- AskIs the credential scoped, hashed at rest, rotatable, and instantly revocable?
- AskAre partners rate-limited and quota'd so one can't overload or overspend?
- AskAre partner calls attributed and audited?