Testing a Centrali API call locally used to mean: open the OIDC token endpoint docs, craft a client_credentials request with the right grant_type, client_id, client_secret, and resource parameters, copy the resulting JWT, paste it into your curl command, and hope it hasn't expired by the time you've typed the rest.
That's three steps too many.
One-Click Tokens from the Console
Open any service account in the console, go to the Keys tab, and click Generate Dev Token. Pick an expiry — 1 hour, 8 hours, 24 hours, or 7 days — and you get a ready-to-use bearer token with a curl snippet you can copy and run immediately.
The token inherits all of the service account's permissions. No extra configuration, no scope selection, no audience confusion.
Better Error Messages When Things Go Wrong
Dev tokens include a special claim that tells Centrali's auth layer "this is a dev token." When the token expires or can't be verified, instead of a generic 401 Unauthorized, you get a message like:
This dev token expired at 2026-03-27T04:00:00Z. Generate a new one in Console > Service Accounts.
Regular service account tokens still return terse 401s — the actionable messages are only for dev tokens, so there's no information leakage in production.
When to Use Dev Tokens vs. Publishable Keys
| Scenario | Use |
|---|---|
| Frontend app (React, browser) | Publishable key — safe to embed in client code, scoped to specific collections |
| Local API testing (curl, Postman) | Dev token — full service account permissions, short-lived |
| Server-side app (Node.js, Python) | Service account — use the standard client_credentials flow for production |
| CI/CD pipeline | Service account — automated token refresh via OAuth |
Dev tokens fill the gap between "I need to test one API call" and "I need to set up a full OAuth flow." They're not for production — they're for getting things done quickly during development.
Available Now
Dev tokens are available in Centrali 4.4.3. Open any service account's Keys tab to try it.