Skip to main content
Biqli accepts workspace API keys and OAuth access tokens as Bearer credentials. Use a workspace API key for a trusted service that manages one workspace. Use OAuth when users connect their own workspaces to your product. This page documents workspace API keys. For OAuth, start with Build your own integration or use the OAuth protocol reference. Every workspace 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: For resource groups with read and write operations, selecting Write includes their read, create, update, and delete abilities. Write-only groups, such as Conversions, grant only the ability shown. 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.
Use biqli_... workspace keys only on trusted servers. Browser tracking uses a separate biqli_pk_... publishable key, allowed hostnames, and the client tracking endpoints. Native Mobile Apps use an app-scoped biqli_mobile_pk_... key only with the mobile-open resolver. The three credential types are not interchangeable. See Mobile security and privacy.