Authentication
Store, send, rotate, and revoke API keys safely.
The public API authenticates programs with API keys. You can purchase access and manage keys from API access. The automation endpoints are separate and use the signed-in user's bearer token.
Send an API key
The recommended transport is X-API-Key:
X-API-Key: pi_live_…Bearer transport is also accepted for clients that cannot configure a custom header:
Authorization: Bearer pi_live_…Do not send both headers. Never put a key in a URL or query parameter, where it can leak through access logs and browser history.
Keep keys server-side
- Store keys in a secret manager or encrypted deployment variable.
- Inject the key into your backend process at runtime.
- Redact
X-API-KeyandAuthorizationfrom request logs and error reports. - Use a separate key for each environment and integration.
- Rotate a key immediately if it appears in source control, a support ticket, or client-side code.
The API currently issues pi_live_… keys only. A browser playground is therefore disabled in the public reference until isolated test keys and a sandbox exist.
Key lifecycle
A new key is shown in full exactly once. Only a SHA-256 hash is stored by Praven Intelekt. Listing keys returns their name, prefix, tier, status, and timestamps—not the secret.
Revocation takes effect immediately on the worker handling the request and within 60 seconds across other workers while authentication caches expire. During rotation:
- Create the replacement key.
- Deploy it to the consumer.
- Verify successful requests with the replacement.
- Revoke the old key.
Key-management authentication
POST /v1/keys, GET /v1/keys, and POST /v1/keys/{key_id}/revoke require a signed-in Praven Intelekt user's Supabase bearer token. They do not accept an API key. For normal use, manage keys through API access, which calls these operations for the signed-in user. If you automate key management, call them only from a trusted server-side process. Do not put a user-session token in the integration code that sends legal API requests.
GET /v1/account and PATCH /v1/account/overages use the same user-session authentication. The latter controls only whether paid overages are enabled and their monthly cap; unit prices remain server-controlled.
Authentication errors
| Code | Meaning | Action |
|---|---|---|
missing_api_key | No accepted key header was present. | Add X-API-Key or bearer auth. |
invalid_api_key | The key format or secret is unknown. | Check the deployed secret; do not retry unchanged. |
revoked_api_key | The key has been disabled. | Replace it with an active key. |
All three return HTTP 401 with the standard error envelope.