How should an enterprise software startup design its API keys and service accounts screen?

Illustrative situation: a startup sells shipment-delay alerts through an API, and a food distributor with a nightly integration is its largest customer. In a security review, the distributor’s platform lead asks three questions. Who owns each key? When does each one expire? What happens to the key an engineer made before he left? The startup’s settings page has one “Generate key” button and a table of keys named “key 1” and “key 2,” with no creator shown. Nobody can say which key the nightly job uses, so nobody dares delete any. The scene is invented. It shows the gap this guide covers: the product issues credentials, and the customer cannot manage them.

Humbleteam, a digital product design agency, publishes this guide. It covers key ownership, the create form, shown-once secrets, rotation, usage information, admin policies, expiry warnings, leak handling and the empty state, with a worksheet and an invented worked example. Product behavior is described as of November 5, 2026 and can change. This is not security advice: your security team and your customers’ security teams decide what policy requires.

Who opens this screen, and what is each person deciding?

Four people open it. This list is our reading, not research.

• The developer creates a key and wants access working in minutes.
• The IT or security admin must know who owns every credential and stop one fast.
• The on-call engineer meets a 401 at night and must learn whether a key expired or was revoked.
• The customer’s security reviewer asks for a key inventory and a maximum lifetime.

One inventory can answer all four: a list with owner, expiry and last use, plus an admin panel for policy. Our guide to SSO and SCIM setup covers removing a person. This one covers the credentials that person leaves behind.

Should a key belong to a person or to a service account?

Both, and the screen should say which. A personal key acts as one human, and vendors differ on what happens when that human leaves.

Datadog ties application keys to their creator. If the user’s account is disabled, those keys are revoked, but API keys created by that account are not deleted and stay valid. Application keys are not transferable, so shared use belongs on a service account. Anthropic’s authentication docs say personal keys are archived when the user is removed from the organization. Its Admin API FAQ says service account keys keep working after the person who created them is removed, and stop only when the service account is archived. GitLab’s service accounts are non-human users for pipelines and integrations, built so credentials stay stable when team membership changes. They use no seat, and by default only administrators or top-level group owners can create them.

Our suggestions: split the list into Personal and Service accounts, make Owner a required column and flag any key whose owner has left. Give each service account a named responsible team. When someone is removed, list their keys in the offboarding summary instead of revoking or keeping them silently.

What should the create-key form ask?

Four fields, in this order: name, access, environment and expiry.

Name. Atlassian tells users to give a token a name that describes what it does. Stripe’s create flow adds a note field for where the key is stored.

Access. Stripe says to use restricted keys for most cases and does not recommend unrestricted secret keys for new ones. GitHub says fine-grained tokens can be limited to specific repositories and permissions, while classic tokens grant access to all repositories in the organizations the person can reach. Twilio offers Main, Standard and Restricted keys. Our suggestion: default to the narrowest choice and state what the key can do in plain words, such as “can read shipments, cannot change them.”

Environment. Stripe keeps sandbox and live mode apart: each has its own keys, and objects in one mode are not reachable from the other. Its prefixes (sk_test_, sk_live_) show the mode even in a log line. Make environment a required choice and show it in the list.

Expiry. Anthropic offers 3 hours, 1 day, 7 days or 30 days, a custom duration or Never, and says the expiration cannot be changed after creation. Atlassian allows 1 to 365 days and defaults to one year. Our suggestion: require an expiry, preselect a short one and say on the form whether it can be edited later.

How should the secret be shown, copied and stored?

Show it once. Stripe displays a live secret key one time, though in sandbox mode you can always see your keys. Atlassian says a token cannot be recovered after creation. Datadog’s One-Time Read mode makes application key secrets visible only at creation, and it is on by default for parent organizations created after August 20, 2025. Twilio’s Console asks the user to copy the secret and tick “Got it!” before finishing.

Our suggestions: one dialog, a copy button and a finish button that waits for a confirmation. After closing, show only the prefix and last four characters; Anthropic’s Admin API likewise returns a partially redacted hint, never the key. Tell the user a lost key is replaced, not recovered. Never put the full secret in the list, an email or an audit entry.

How should rotation work without an outage?

Rotation fails when the old key dies before every caller has switched. Stripe’s dashboard rotation keeps old and new keys working together for up to 7 days, and advises expiring the old key only after its request volume has sat at zero for hours or days. GitLab’s rotation has no overlap: it invalidates the old value, and services that rely on it stop working. Google Cloud warns that an expired service account key can cause an accidental outage.

Vendors also separate stopping a key from deleting it. Anthropic’s Console separates a reversible Disable from a permanent Delete, and Datadog keeps a revoked API key restorable for 7 days. Our suggestions: a Rotate action with a chosen overlap, the old key’s last use beside it, Disable before Delete, and a plain warning on anything irreversible.

What should the list say about use?

Datadog shows a Last used timestamp to all customers. Stripe links each key to its request logs. GitLab’s token view shows usage dates and the last five distinct connection IP addresses. Anthropic’s Console table shows each key’s expiration, and its Admin API reports status.

Our suggested columns: name, owner, type, environment, prefix, created, expires, last used and status. Sort by expiry. Add one filter for keys with no recent use and one for keys without an owner.

Which admin policies and network limits belong on the page?

Admins want to set a rule once and have every key follow it. GitHub lets organization owners require approval for fine-grained tokens, block either token type and cap lifetime, though a lifetime policy does not revoke tokens that already exist. Anthropic’s maximum expiration policy removes the Never option and limits presets. Atlassian’s authentication policies can block members from creating tokens at all, and Google Cloud has constraints that disable service account key creation.

For network limits, Stripe lets an access policy limit a key to IP addresses, networks, countries or threat categories, blocks other requests and notifies you. GitHub’s IP allow list covers personal access tokens and warns that losing access to a listed address can lock you out.

Our suggestions: put policy in its own panel, preview the effect before saving (“14 existing keys exceed 90 days”) and keep a break-glass path for a lock-out. Our guide to roles and permissions covers who may edit the panel.

How should expiry warnings and leaks be handled?

Warn before a key dies. Anthropic emails the key’s creator 7 days before expiry for keys with a lifetime of at least 14 days, and 1 day before for keys of at least 7 days. Shorter-lived keys get no email. GitLab emails users 7 days before, plus 30 and 60 days on version 17.6 and later. Both warn the creator or user, so a departed creator hears nothing. Our suggestion: notify the owner and an admin group, and show a banner in the list.

Leaks need a response too. GitHub’s secret scanning notifies the provider when it finds a partner secret so the provider can revoke it, and GitHub revokes its own tokens pushed to a public repository. Stripe says it may notify you or deactivate an exposed key, and does not promise to detect every one. Google Cloud can disable leaked service account keys when an organization policy asks it to, also with no guarantee. Our suggestions: use a recognizable prefix so scanners can match your keys, mark an auto-disabled key with its reason and record the event in the audit log.

What should the screen show before the first key exists?

An empty table reads as broken. Say what a key is for, offer “Create sandbox key” first and show the rules that will apply, such as “Keys expire after at most 180 days.” The service accounts tab needs its own message: “No service accounts yet. Create one for each production system.” Where your product should connect through OAuth instead of a customer-held key, point to our integrations guide.

Which fields does each part of the screen need?

Illustrative worked example: a delay-alert startup and a food distributor

Everything here is invented. Corvane is a fictional startup that sells shipment-delay alerts through an API. Pellam Foods is a fictional customer. Mara Quist leads Pellam’s platform team, and Jonas Hale is an engineer who left Pellam last spring.

Mara opens Corvane’s list and sees five keys. “nightly-sync” was made by Jonas Hale, now marked “removed.” It has no expiry, and its last use was yesterday. She creates a service account, “delay-sync,” owned by her team, and a live key with a 90-day expiry, under the 180-day cap Pellam’s admins set in Corvane. She rotates with a 14-day overlap, Corvane’s own limit.

During the overlap, the old key’s last-used time stays fresh for 9 days, then stops: a forgotten script had been calling it. Mara disables the old key, waits a week, then deletes it. She adds an allow list for Pellam’s network range and sends expiry reminders to her team’s alias at 30 and 7 days. The scene stops before the first renewal. It shows the owner column, the overlap and the last-used column doing the work.

Where do these defaults stop working?

The sources are vendor documentation. None of them measures whether better key screens reduce incidents or review time. Some features depend on plan: GitLab caps free-tier service accounts at 100, and Atlassian includes five free service accounts per organization. A startup can begin with owner, expiry, last used and a rotation overlap.

We found no update date on the Anthropic, Datadog and Twilio pages. Twilio’s docs do not state that its secret is shown only once, so we describe only the “Got it!” step. We left out OpenAI’s console because its pages blocked automated reading. A static key may also be the wrong tool. Google tells readers to choose a more secure alternative where possible, and Anthropic offers workload identity federation, which removes the static key. Requirements vary by customer, so involve security staff before you promise any of this.

What can you produce now?

Five things, before the next security review:

1. A rule for who owns a key, and what happens to it when its owner leaves.
2. A create form specification: name, owner, access in plain words, environment and a required expiry.
3. A secret dialog and rotation flow with a chosen overlap and a last-used readout.
4. A policy panel specification: maximum lifetime, who may create keys, network limits and a lock-out path.
5. A notification and leak plan: who hears at 30 and 7 days, and what an auto-disabled key looks like.

If you want a design partner for these screens, our comparison of agencies that publish B2B SaaS platform cases shows what each one publishes.