Skip to main content
The Biqli API lets you programmatically create and manage resources in a Biqli workspace. It uses predictable REST endpoints, JSON payloads, and workspace-scoped API keys.
The current API is designed for server-to-server integrations that manage one workspace. It is not a browser API or an OAuth partner authorization flow.

What you can build

Links

Create, retrieve, update, list, count, and bulk-manage short links.

Custom domains

Connect domains, retrieve DNS instructions, and verify configuration.

Folders and tags

Organize links and manage their folder and tag associations.

Tracking pixels

Manage supported retargeting-pixel configurations and link attachments.

QR codes

Create and style standalone static or dynamic QR codes.

Biolinks

Manage Biolink page-level settings without exposing frontend-owned widgets.

Quick start

1

Create a workspace API key

Open Workspace settings → API Keys, select Create API key, and grant only the permissions your integration needs. The secret is displayed once.See Authentication for the complete key and permission model.
2

Store the key on your server

Save the key in an environment variable or secret manager. Never include it in browser code, mobile applications, public repositories, or logs.
.env
3

Make your first request

List the first ten links in the key’s workspace:

Base URL

All endpoints use HTTPS and are versioned under this base URL:
Unencrypted HTTP is not supported. Endpoint pages show paths relative to this base URL, such as GET /link.

Authentication and workspace scope

Send your biqli_... secret in the Authorization header:
The key selects exactly one workspace. Do not send workspaceId, workspace_id, internal numeric IDs, or frontend model fields. Requests are also checked against the key’s resource permissions and the key creator’s current workspace role. Read Authentication for creation, permissions, rotation, and revocation guidance.

API conventions

  • Send Accept: application/json on every request.
  • Send Content-Type: application/json when a request has a JSON body.
  • PATCH changes only fields included in the request; omitted fields are preserved.
  • Successful creates return 201 Created unless an endpoint documents another result.
  • Successful deletes return 204 No Content with an empty body.
  • Collection endpoints use cursor pagination with starting_after and ending_before; see Pagination.
  • external_id lets your system address supported resources with its own stable identifier.

Public resource IDs

Biqli returns typed public identifiers instead of internal database IDs: A valid identifier belonging to another workspace returns the same 404 resource_not_found response as an identifier that does not exist.

Responses and errors

Successful JSON responses contain the named resource and a success status:
Errors use one machine-readable envelope:
Every API error returns the request identifier in both the JSON body and the X-Biq-Request-Id response header. You may send your own X-Biq-Request-Id value of up to 100 characters to correlate a request across services. Include it when contacting support. Read Errors for stable error codes, structured details, retry decisions, and partial bulk failures.

Rate limits

Biqli applies the workspace plan’s fixed one-minute request allowance. Successful responses expose the current quota through the IETF HTTPAPI RateLimit-Policy and RateLimit fields. A throttled request returns 429 Too Many Requests, the same quota fields, and Retry-After. Read Rate limits for field syntax, quota scope, and retry guidance.

Next steps

Authentication

Create a key and choose the least-privilege permission set.

Rate limits

Read quota fields and implement safe throttling behavior.

Errors

Handle stable error codes, request IDs, and partial bulk failures.

Pagination

Traverse every list endpoint with forward and backward cursors.