API Key Management for SaaS: Beyond the Settings Page

Most SaaS products reach a point where they expose an API. They add a "Developer Settings" page, let customers generate keys, and move on. Six months later, no one knows how many keys exist, which ones are active, who created them, or which integrations would break if a key were rotated.

API key management is one of the most commonly underdeveloped areas of SaaS backoffice infrastructure — and one of the most consequential when something goes wrong.

What the settings-page approach misses

A basic API key UI lets customers generate and revoke keys. It doesn't give you or your customers:

• Visibility into usage — which keys are making requests, how often, and from where
• Scoped permissions — keys that can only perform certain actions (read-only, write, admin)
• Expiration dates — keys that automatically expire after 90 days or on a defined date
• Rotation workflows — a way to issue a new key and retire the old one without downtime
• Audit log — a record of when each key was created, last used, and by whom

Without these, your security posture depends on customers managing their own keys responsibly — which they won't, consistently, at scale.

The internal visibility problem

Your support team should be able to answer: "Is this customer's integration actively using their API key, and when did it last make a request?" Your security team should be able to answer: "Are there any keys that haven't been used in 180 days?" Without an internal API key dashboard, these questions require a database query.

An internal key management panel gives your team:

• A list of all active keys across all customer accounts
• Last-used timestamp and request volume per key
• One-click revocation for compromised or abandoned keys
• Flags for keys that are old, unused, or over-privileged relative to what the integration actually does

Scoped permissions reduce blast radius

A key with read-only scope that gets leaked is a much smaller incident than a full-access key. Scoping is straightforward to implement — you define the permission set, associate a scope with each key at creation time, and enforce that scope in your API middleware.

The challenge is designing a permission model that's granular enough to be useful but simple enough that customers can understand it. For most SaaS products, three tiers (read-only, read-write, admin) cover the vast majority of real integration patterns.

Key rotation without downtime

Enterprise customers with security-conscious engineering teams rotate API keys periodically. If your product doesn't support rotation gracefully — a way to issue a new key while the old one stays active for a transition window — you'll get support tickets every time a customer tries to rotate.

The pattern: customer generates a new key, updates their integration, then revokes the old one. The system should support both keys being active simultaneously during the transition, with a configurable window before the old key auto-expires.

When to build this

The trigger is usually either a security incident (a leaked key, an unexpected integration doing something it shouldn't) or an enterprise customer asking for audit logs of API key activity as part of a security review. At that point, the absence of proper key management becomes a deal blocker, not just a backlog item.