---
title: "API Key Week Wrap Up"
description: "We spent the week on API keys. Best practices, a self-serve settings page, dual-auth on a single route, and provisioning a key the moment a user signs in. The whole week in one place."
canonicalUrl: "https://zuplo.com/blog/2026/05/08/api-key-week-wrap-up"
pageType: "blog"
date: "2026-05-08"
authors: "martyn"
tags: "API Key Authentication, API Security, Developer Experience"
image: "https://zuplo.com/og?text=API%20Key%20Week%20Wrap%20Up"
---
API keys are the auth pattern that quietly powers most public APIs and almost
every AI agent integration in 2026. We spent the week on the parts that don't
get written about: the design choices, the lifecycle work, and the
implementation patterns that separate a key system that scales from one that
gets ripped out a year later.
## Monday: API key best practices for 2026
Josh kicked the week off with the nine practices that separate an API key system
that scales from one teams rebuild a year in, drawn from years of shipping API
products and helping Zuplo customers do the same.
The big call is whether to ship retrievable keys (viewable again from the
dashboard, stored encrypted at rest) or irretrievable ones (shown once at
creation, then stored only as a one-way hash), and the post explains why neither
is universally better. The other eight practices cover prefixes, checksums,
caching, secret scanning, dashboard UX, rotation windows, snake_case naming, and
the per-request validation flow that ties them together.
[Read the post](/blog/2026/05/04/api-key-best-practices)
## Tuesday: the missing manual for API keys
There's no RFC for API keys. No standard. Every provider does it slightly
differently, and if you're designing a key system you piece the answer together
from blog posts, source code, and whatever Stripe shipped this week.
So we built the guide we wished existed: [apikeys.guide](https://apikeys.guide).
Anatomy of a good key, where to send it, how to hash and store it, how to prefix
for secret scanning, rotation and revocation, public versus secret keys, and
rate limiting per key. Free, open source, and structured so an AI assistant can
read it without hallucinating the answer.
[Read the post](/blog/2026/05/05/introducing-apikeys-guide)
## Wednesday: add self-serve API keys to your own app
Sooner or later your API needs a settings page where users mint, rotate, and
revoke their own keys. The list of things to get right is long: hash on write,
surface plaintext exactly once, mask forever after, propagate revocations,
support rotation without breaking integrations, detect leaked keys.
The post shows how to skip all of that by wiring your settings page into Zuplo's
Bucket API (the HTTP surface that mints, lists, rotates, and revokes keys
against a named bucket, the per-environment container that holds your consumers
and their keys). Five operations, four layers, and a stack-agnostic contract
that's the same whether your backend is FastAPI, Rails, Express, or Go.
[Read the post](/blog/2026/05/06/add-self-serve-api-keys-to-your-own-app)
## Thursday: JWT and API key auth on the same route
The web app authenticates with OAuth. An MCP client (the bridge that connects an
AI assistant to an MCP server fronting your API) shows up next carrying a JWT
for whoever is signed into it. The customer's data pipeline still wants an API
key. All three need to call the same endpoint, and the usual answer ("pick one
and tell the other teams to deal with it") is wrong.
Thursday's post wires a Composite Inbound policy (a Zuplo built-in that chains
inbound policies and runs them as a single unit) that runs both validators with
`allowUnauthenticatedRequests: true`, then a five-line guard rejects anything
that came out the other side without a `sub` (the JWT subject claim, also
populated from API key consumer records). Same handler, same `request.user`
shape, regardless of which credential arrived.
[Read the post](/blog/2026/05/07/using-jwt-and-api-key-auth-on-the-same-route)
## Friday: provision API keys at first login
A new user signs into your developer portal. They open the API reference, hit
the playground, and there's nothing there. No key. One more click between them
and their first successful request.
That click doesn't need to be there. Most auth providers expose a hook into the
signup flow, and Friday's post uses an Auth0 Post Login Action to call the Zuplo
Developer API and mint a consumer (Zuplo's identity object that owns one or more
keys) plus a key before the portal page renders. Same idea maps to Clerk,
Supabase, and Firebase Auth.
[Read the post](/blog/2026/05/08/provision-api-keys-at-first-login)
## API keys are a product surface, not a primitive
That's the through-line of the week. API keys are not a string you bolt on,
they're a product surface with a lifecycle.
If you're building an API key system from scratch, or auditing one that grew
organically, Zuplo's API key service ships every practice covered this week
(prefixes, checksums, edge caching,
[GitHub secret scanning](https://docs.github.com/en/code-security/secret-scanning/secret-scanning-partner-program/secret-scanning-partner-program),
rotation with grace windows, retrievable keys as the default with irretrievable
as an option) in one managed component you can drop in front of any API.