Authentication

Every request needs a bearer token in the Authorization header. Keys are shown once when you mint them, so save the value before closing the banner. Revoked keys stay in the system so their usage history remains queryable.

Bearer token

Every request under /v1/* must carry an Authorization header:

Authorization: Bearer sk_live_yourkeyhere

Missing header, malformed header, or an unknown/revoked key returns 401 unauthorized — no body distinguishes the modes, so a scanner can't fingerprint valid-vs-invalid keys.

Managing keys

Mint / list / revoke keys at /account/api-keys. Auth via Google OAuth — same session powers the rest of the site.

  • Raw secret shown once. The mint page displays the full key in a dismissable banner. After you close it, only the first 8 characters (display prefix) are retrievable — enough to identify the key without exposing it.
  • Server stores the SHA-256 hash of the key, never the raw value.
  • Revoke is soft delete. A revoked row stays for audit (last_used_at, last minted date) but stops authenticating.
  • Rotate anytime — mint a new key, redeploy, revoke the old one.

WebSocket authentication

Browser WebSocket clients can't set arbitrary headers on the upgrade request, so the API key goes on the query string:

wss://api.cookin.fun/socket/websocket?vsn=2.0.0&api_key=$API_KEY

Non-browser clients (Node bots, server-side aggregators, curl) can also send Authorization: Bearer on the upgrade — either works. If both are present the query param wins (explicit choice).

Bug or unclear docs? Include the request_id from the response envelope when reporting.

Ready to build? Mint an API key.