Practical guide

How to Track API Key and Client Secret Expiration Dates

A lot of "the integration is down" incidents are not bugs. A client secret or API key reached its expiry date, the service started rejecting requests, and nobody had a reminder because the person who created the credential set it up once and moved on.

November 2, 2026 · 7 minute read

The integration worked yesterday

Expiring credentials are renewals with a different failure mode. A missed software renewal usually means an unwanted invoice. A missed credential expiry usually means something stops working: a sync, a sign-in, a payment webhook, a nightly export.

This guide covers how to track API key and client secret expiration dates so every credential that can expire has a date, an owner, and a reminder early enough to rotate it calmly.

Which credentials actually expire

Not every key has an expiry date. Many do, and the ones that do are easy to forget. Common examples:

Client secrets on app registrations used for single sign-on, directory sync, or API access
API keys and access tokens that a provider issues with a fixed lifetime, or that your own policy requires you to rotate
Service account keys used by scripts, backups, and scheduled jobs
Personal access tokens that an employee created for an automation
Signing and encryption certificates tied to SSO or API authentication
Webhook signing secrets that your policy says to rotate on a schedule

Lifetimes vary a lot by provider and by the choice made when the credential was created. Check the expiry date the provider shows for each one rather than assuming a default.

Step 1: Build an inventory of names and dates, never secrets

The inventory is a list of credentials, not a vault. Record what a credential is and when it expires. Never paste the secret value into a tracker, spreadsheet, ticket, or email.

For each credential, record:

Name:the label it has in the provider's console
Provider or system: where it was issued
What it powers: the integration, job, or app that breaks if it expires
Expiry date: copied from the provider, not estimated
Rotation lead time: how long it realistically takes to issue a new one, update every place it is used, and test
Named owner and backup
Where it is used: the systems or configs that hold it, so nothing is missed during rotation
Where to rotate it: a link to the console page or runbook

Start with the credentials behind your most important integrations: SSO, payroll, billing, backups, and customer-facing APIs. Then work outward.

Step 2: Give every credential a named owner

Credentials are often created by whoever was setting up an integration that day. That person may change teams or leave. If nobody else knows the key exists, nobody gets warned.

Assign an owner who is responsible for rotating it and a backup who can cover. Use a person, not a team alias. If you are not sure how to choose, who should own software renewals covers the same thinking. When someone leaves, include their credentials in the handoff; see the renewal owner offboarding handoff checklist.

Step 3: Count reminders back from the rotation lead time

The date that matters is not the expiry date. It is the last day you can start rotation and still finish before expiry. A credential used in one script may take ten minutes. A credential shared across several systems, or one that needs a vendor or another team to update, may take weeks.

Set a sequence of reminders counted back from that start date, not a single email the day before. The 90/60/30-day renewal reminder schedule is a reasonable starting point for long-lived credentials; shorten it for credentials with short lifetimes. Send reminders to the owner and backup directly, not to a shared alias; why shared inboxes fail as renewal reminder recipients explains why.

Step 4: Write a short rotation runbook

Rotation goes wrong when it is improvised. For each important credential, keep a few lines:

Where to create the new credential
Every place the old one is stored or referenced
The order to update them in
How to confirm the integration still works
When to revoke the old credential, after the new one is confirmed
The new expiry date, recorded in the inventory the same day

Where the provider allows two valid credentials at once, create the new one, switch over, confirm, then revoke the old one. That avoids a gap.

Step 5: Review the list on a schedule

Inventories drift. New integrations get added, old ones get retired, owners move. Add credentials to your regular review:

Every credential expiring in the next two quarters has an owner, backup, and reminders
Retired integrations have their credentials revoked and removed from the list
New integrations added since the last review are on the list
Anyone who left or changed roles has been replaced as owner

If you do not have a regular review yet, how to run a quarterly renewal review meeting gives you an agenda you can extend to credentials.

Treat certificates and domains the same way

Client secrets often sit next to other technical expirations that cause the same kind of outage. If you are building this list, add SSL certificates and domains too. See the SSL certificate expiration checklist and the domain and DNS expiration checklist. For a broader approach across every kind of expiring item, see how to track expiration and renewal dates without missing one.

Common mistakes

Storing secret values in the tracker instead of names and dates
Relying on the provider to warn you, with alerts going to an admin role nobody watches
Listing the person who created the key as owner after they left
One reminder the day before expiry
Revoking the old credential before the new one is confirmed working
Forgetting to record the new expiry date after rotation

Spreadsheet version

A spreadsheet works for a short list. Use one row per credential with the fields above, plus a column for "rotation start by" (expiry date minus lead time). Sort by that column so the next rotations are at the top. Add a check column that flags any row with no owner or no expiry date. Keep secret values out of the sheet entirely.

When the list grows, or reminders live in one person's calendar, see how to move renewal tracking out of spreadsheets.

FAQ

How do I find when a client secret expires?

Look in the provider's console where the credential was created. Most show an expiry or "valid until" date next to each secret or key. Copy that date into your inventory rather than estimating it.

How far ahead should we be reminded?

Far enough to finish rotation calmly. Work out how long rotation really takes for that credential, including any other teams or vendors involved, and start reminders well before that point.

Should we store API keys in our renewal tracker?

No. Track the name, owner, expiry date, and where it is used. Keep the secret itself in your secrets manager or the provider's console, never in a tracker, spreadsheet, or email.

Who should own an API key or client secret?

A named person who can rotate it, plus a backup. Usually that is someone on the team that runs the integration, not necessarily the person who created the key.

What about keys that never expire?

They do not need an expiry reminder, but many teams still set a rotation date by policy. Track that date the same way.