[eseidel]

Since today's prod deploy (shorebirdtech/_shorebird#3883), a new personal API key always expires, in a year by default and at most a year; the console no longer offers Never. The API keys page still lists No expiration as an option, so it's now wrong.

Changes

• account/api-keys.mdx: drops No expiration, says a key can't be set to never expire, that existing never-expiring keys keep working (regenerating one gives it an expiration), and points at service accounts for a key that never expires.
• account/api.mdx: its token summary no longer lists no expiration.
• public/auth.md: its key lifespan no longer offers no expiration.
• Changelog entry personal-key-expiry.md, dated 2026-10-20.

Screenshots

No visible change beyond the edited Expiration section and one changelog entry.

Landing

As soon as approved.

🤖 Generated with Claude Code

[eseidel]

Adversarial review (separate agent, no context from the author)

1. Medium. account/api.mdx:94-95 still says personal keys can be set to "no expiration". After this PR, it contradicts api-keys.mdx.
2. Medium. "A key created through the API with no expires_in_days" points at POST /api/api-keys on auth, which no docs page describes, and which an API key can't call anyway. Readers will confuse it with the service-account endpoint, where null means never. Drop the sentence and phrase the 1-year cap in console terms.
3. Low. "All expiration options are available on every plan." is now a sentence that says nothing.
4. Low. "keeps working when you leave the organization" is imprecise: a personal key keeps working, it only loses that org. Suggest "doesn't depend on any one person's account".
5. Low. Doesn't say that regenerating an old never-expiring key gives the new key an expiration.

Checked and fine: the date, frontmatter, the anchor and link, the claims against #3883, and CI.

[eseidel]

All five are addressed in be3b4f4:

1. Fixed: api.mdx now lists 30 or 90 days and drops no expiration.
2. Fixed: the API sentence is gone from both the page and the changelog. The cap is now stated as "A key can't be set to never expire."
3. Fixed: the plan sentence is deleted.
4. Fixed: "doesn't depend on any one person's account", in both files.
5. Fixed: the page says regenerating an old key gives the new key an expiration, and the changelog says Never is gone when you create or regenerate a key.

[AbhishekDoshi26]

4 findings.

1. src/content/changelog/personal-key-expiry.md:11-12: the entry says the Console "no longer offers No expiration", but the option was labeled Never (web/apps/console/app/components/api-keys/api-key-creation-form.tsx:74 in _shorebird, { value: 'never', label: 'Never' }). Suggest: "The Console no longer offers Never as an expiration when you create or regenerate one."

2. src/content/docs/account/api-keys.mdx:62: "Keys created before October 20, 2026 without an expiration" misses part of a day. #3883 first reached prod in the "Deploy All to Prod" run that started 2026-10-20 13:57Z (06:57 PDT), so keys created earlier on October 20 can also be non-expiring. The date isn't needed: "Existing keys without an expiration keep working until you revoke them."

3. src/content/docs/account/api.mdx:94-95: this bullet covers every sb_api_* key, and service account keys share that prefix (packages/shorebird_frog/lib/src/api_key_prefix.dart:6) and can still be set to never expire (SERVICE_ACCOUNT_KEY_MAX_EXPIRY_DAYS, the creation form shows Never for holder === 'serviceAccount'). Dropping "no expiration" outright makes it wrong for service account keys. Suggest: "Default expiration is 1 year, with options for 30 or 90 days, and only a service account's key can be set to never expire."

4. src/content/changelog/personal-key-expiry.md:4 (nit): area: API, but after the earlier review removed the API sentence the body only describes the Console. Suggest area: Console.

Checked and correct: #3883's date (first prod deploy containing merge a5c8698 is the 2026-10-20 PDT run), the 1-year default and 365-day max with allowNever: false on the personal create and regenerate routes, regenerate giving the new key an expiration, existing keys untouched, no CLI path that creates keys, no other page or agent file describing personal key expiry, template shape and the #expiration anchor.

I'll push fixes for these.

[AbhishekDoshi26]

2 findings.

Round 2, full diff at 21d0005. All four round-1 fixes landed (Never label, no October 20 cutoff, api.mdx covers service account keys, area: Console).

1. public/auth.md:28-29: the agent-facing auth guide (linked from public/.well-known/agent.json and the llms details in astro.config.mjs) still says "you can choose 30 days, 90 days, or no expiration instead". Round 1 missed it; it's the last stale mention in the repo. Suggest (Prettier-stable):

   - **Lifespan**: 1 year by default. When creating the key, you can choose 30 or
     90 days instead. Only a service account's key can be set to never expire.
   

2. PR description (nit): "the console no longer offers No expiration", but the Console label was Never (api-key-creation-form.tsx:74). Suggest "the console no longer offers Never", and add public/auth.md to the Changes list.

Re-checked: #3883 (a5c8698e0) first reached prod in the 2026-10-20 06:57 PDT run with code-push-console and code-push-auth green; personal create and regenerate use allowNever: false with a 365-day max; Never is shown only for service accounts; service-accounts.mdx agrees; Prettier passes; no em-dashes.

I'll push the fix and update the description.

[AbhishekDoshi26]

No findings.

Round 3, full diff at a212b99 plus the description. Round 2's fixes landed: public/auth.md no longer offers no expiration and says only a service account's key can be set to never expire, and the description says Never and lists auth.md. A whole-repo grep for expiry wording (src, public including .well-known, astro.config.mjs) finds nothing else that contradicts the PR. Re-checked against _shorebird: Never hidden unless holder === 'serviceAccount', 1-year default, allowNever: false with a 365-day max on personal create and regenerate, regenerate always gives an expiration, no migration of existing keys, service account keys can still be never, and 2026-10-20 is the PDT day of the first prod deploy containing a5c8698e0. Template, anchor, Prettier and em-dash checks pass.