Authorization header:
API keys
An API key controls four things:
- Usage and credits. Calls are attributed to the account or team that owns the key.
- A dedicated rate limit. Requests are counted per key, not per IP. See rate limits.
- Account-scoped attribution. Keyed searches are recorded to your account, and
/v1/feedbackreferencing asearch_idordoc_idis checked against that ownership. Your feedback provably belongs to your searches. - Document grants.
/v1/documentlookups bydoc_idresolve documents your account has been granted — by appearing in your search results or by a prior directcanonical_urllookup.
Getting a key
Create keys in the Caesar app. Store the secret once; the full key is only shown at creation time.
Key format
Console-issued keys start withcsk_. Legacy alpha keys may start with sk_live_, followed by a 12-character key_prefix and a longer secret. Non-secret key prefixes are safe to display in dashboards and logs to identify a key. The full key is returned exactly once at creation and stored only as a hash; it cannot be retrieved again.
Scopes
New keys get all three scopes by default. Calling an endpoint your key lacks the scope for returns
403:
Invalid keys are rejected
Every API request must authenticate. A missing, malformed, unknown, expired, or revoked key returns401:
One environment variable everywhere
Every first-party client readsCAESAR_API_KEY:
--key flag, and the MCP server accepts it as a Bearer header. If the variable is unset and no key is stored in client config, API calls fail with 401 missing_api_key.
Client attribution: X-Caesar-Client
First-party clients send an attribution header of the formX-Caesar-Client: cli/0.2.0 (or python-sdk/0.2.0, ts-sdk/0.2.0). It is a convention, not a contract: the server does not validate or act on it. If you build on the raw API, sending X-Caesar-Client: yourtool/1.2.3 is encouraged because it helps the Caesar team understand client traffic.