Skip to main content
Biqli authenticates workspace API requests with secret Bearer tokens. Every API key belongs to exactly one workspace and begins with biqli_.
A Biqli API key is a server-side secret. Never expose it in browser code, mobile applications, frontend bundles, public repositories, screenshots, or logs.

​
Create an API key

1

Open the workspace API key settings

Select the workspace you want the integration to manage, then open Workspace settings → API Keys.
2

Name the integration

Select Create API key and enter a recognizable name, such as Production link sync or Staging automation.
3

Choose permissions

Use Restricted whenever possible and grant only the resources and operations the integration needs.
4

Copy and store the secret

The full key is displayed only once. Store it in a secret manager or protected server environment variable before closing the dialog.
.env
Keys do not expire automatically. They remain valid until revoked, the key creator loses the required workspace access, or the workspace is deleted.

​
Authenticate a request

Send the key using the Authorization request header and the Bearer scheme:
For example:
Do not send API keys in URLs, query parameters, JSON bodies, or cookies. These locations are more likely to be recorded by browsers, proxies, and application logs.

​
Workspace scope

The key itself selects the workspace. Never add workspaceId or workspace_id to public API requests. Resources are isolated by workspace. If a public resource ID is missing or belongs to another workspace, the API returns the same 404 resource_not_found response. This avoids revealing whether a resource exists outside the key’s workspace.

​
Permission modes

When creating or editing a key, choose one of three modes: Selecting Write for a resource includes its read, create, update, and delete abilities. Use the least privilege needed for the integration.

​
Resource permissions

Every workspace key also receives the internal api.access ability required to use the public API.

​
Cross-resource operations

Some writes reference a second resource. The key must be able to read every referenced resource in addition to writing the primary resource. For example, creating a link with domain_id, folder_ids, tag_ids, or pixel_ids requires:
  • links.create
  • custom_domains.view when selecting a domain
  • link_groups.view when selecting folders
  • tags.view when selecting tags
  • tracking_pixels.view when selecting tracking pixels
The same rule applies when updating associations. A 403 insufficient_scope response identifies the missing permission.

​
Key ownership and revocation

An API key cannot grant more access than its creator currently has in the workspace. Requests stop working when:
  • the key is revoked;
  • its creator loses workspace access or required role permissions; or
  • the workspace is deleted.
Revocation takes effect on the next request.

​
Rotate a key safely

1

Create a replacement

Create a new key in the same workspace with the required permissions.
2

Deploy the replacement

Update your server secret and verify a request succeeds with the new key.
3

Revoke the old key

Revoke the previous key only after every integration instance uses the replacement.

​
Authentication errors

Read Errors for the complete response envelope, request tracing, and retry guidance.
Biqli currently provides secret workspace API keys for server-side use. It does not provide a client-side publishable key or an OAuth partner flow.