Skip to main content
Treat a workspace API key like a password. Send it only over HTTPS in the Authorization: Bearer header and keep it in a server-side secret manager or protected environment variable. Use one narrowly scoped key per application and environment. Never place it in client-side JavaScript, mobile application bundles, URLs, logs, screenshots, or support messages. Monitor last-used information and API responses. Rotate a key after suspected exposure, team or vendor changes, and according to your security policy. The public API also returns rate-limit headers that clients should respect.

​
Storage and transport

Store secrets in a managed secret service or protected server environment variable. Send requests only to the documented https://biq.li/api/v1 origin over HTTPS. Prevent request debugging tools from recording the Authorization header.

​
Least privilege

Use Restricted permissions for a focused integration. A reporting job usually needs Read, while a link publisher needs Links Write plus Read for referenced domains, folders, tags, or pixels. It does not need unrelated resource access.

​
Error and rate-limit handling

Log the response status, structured error code, request ID, and safe resource identifier. Do not log the bearer token or passwords. Respect the standardized RateLimit headers and retry 429 responses after the indicated time with backoff.

​
Incident response

Revoke an exposed key, create a replacement, update legitimate consumers, and review activity and last-use data. Rotation does not require a legacy compatibility period when no consumer should retain the old secret.