Skip to main content
Biqli applies a fixed one-minute request quota to protect API availability and ensure fair use. The exact allowance is determined by the workspace’s current plan and is returned with successful responses and rate-limit rejections. All workspace API keys for the same workspace share this allowance. Creating additional keys does not create additional quota.

​
IETF RateLimit fields

The Biqli workspace API follows the IETF HTTPAPI RateLimit header fields Internet-Draft and returns its structured RateLimit-Policy and RateLimit fields on successful responses and rate-limit rejections.
The cited specification is an active Internet-Draft and may evolve. Biqli implements its current RateLimit-Policy and RateLimit field format.
A successful response can include:
The structured parameters mean: The policy name is workspace-api. Biqli does not expose its internal workspace partition key in response fields.
A positive r value is quota guidance, not a guarantee that a future request will succeed. Requests can still fail because of permissions, validation, resource quotas, or temporary service conditions.

​
Legacy compatibility fields

Biqli also returns the existing X-RateLimit-* fields so integrations using them continue to work: Build new integrations against RateLimit-Policy, RateLimit, and Retry-After. The X-RateLimit-* fields are compatibility aliases rather than the current IETF structured format.

​
When the limit is exceeded

When the shared workspace allowance is exhausted, Biqli returns 429 Too Many Requests:
If both Retry-After and RateLimit are present, follow Retry-After.

​
Retry safely

1

Stop sending requests

Pause requests for the affected workspace when the API returns 429.
2

Honor Retry-After

Wait at least the number of seconds in Retry-After. Add a small random delay when many workers could retry simultaneously.
3

Retry deliberately

Retry only the failed operation. Use an idempotent external_id where the endpoint supports it so a network retry does not create a duplicate.
For transient network errors or 5xx responses, use exponential backoff with jitter and a maximum retry count. Do not retry authentication, permission, or validation failures as though they were rate-limit failures.

​
Use the allowance efficiently

  • Use Bulk create links, Bulk update links, and Bulk delete links for large jobs.
  • Request the largest appropriate page_size and follow cursor pagination instead of repeatedly fetching the first page.
  • Cache resource data that does not need to be refreshed on every operation.
  • Use RateLimit proactively and slow workers before r reaches zero.
  • Coordinate concurrent workers because every key in the workspace consumes the same quota.

​
Request limits versus resource quotas

Rate limits control request frequency and return 429 rate_limit_exceeded. They are separate from plan resource quotas, such as the number of links or QR codes a workspace may create. A resource quota or unavailable feature normally returns a 403 error such as quota_exceeded or upgrade_required. Treat every attempted request as potentially consuming quota, including a request that later fails validation. The response fields are the source of truth for the workspace’s currently effective request allowance; do not hardcode a plan limit in your integration. For handling non-rate-limit failures, see Errors.