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.
19:21API Key Authentication Best Practices
Watch Josh walk through the nine practices on YouTube.
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. 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.
1:29Introducing apikeys.guide
A short walkthrough of what apikeys.guide is, who it's for, and why we built it.
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.
9:03Self-serve API keys: end-to-end walkthrough
A walkthrough of the reference implementation: the four layers, the settings page, and the Bucket API calls behind each operation.
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.
8:45JWT and API Key Auth on the Same Route
Watch the dual-auth composite policy in action: one route accepting both credential types and producing a single identity downstream.
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.
10:31Provision API Keys at First Login
Watch the video walkthrough of wiring an Auth0 Post Login Action to the Zuplo Developer API so a new user lands on the portal with a working key.
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, 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.
API Key Management
The full reference for Zuplo's managed API key service: buckets, consumers, keys, rotation, and the Developer API your app calls to mint and manage them.