A headless content API has two kinds of callers, and it's tempting to secure them the same way. That's the mistake.
There's a human logging into an admin UI to edit content, and there's a machine — a website, a build step — pulling published content through a delivery endpoint. They authenticate with different credentials, and those credentials have opposite properties. Treat them identically and you either make the machine path painfully slow or the human path dangerously weak.
I built a small headless content API (Depot) partly to get this boundary right. Here's the reasoning.
The two credentials
A session proves "this human is logged in." Short-lived, rides in an httpOnly cookie, checked on management routes.
