POST /api/v1/knowledge-bases/:knowledgeBaseId/client-keys.
Public client key (browser-safe)
- Prefix:
bq_pk_… - Safe to ship in browsers and mobile apps; scoped to one knowledge base.
- Optional origin allowlist — requests are only accepted from listed origins; wildcards like
https://*.example.comare supported. - reCAPTCHA v3 enforcement — always required for public keys when reCAPTCHA is configured on the server.
Client ID + secret (server-side)
- Prefixes:
bq_ci_…(ID) andbq_cs_…(secret). - For backend integrations only — never expose in client-side code.
- The secret is hashed at rest and shown exactly once on creation.
Header summary
CAPTCHA
Public-key requests must send a reCAPTCHA v3 token whenever reCAPTCHA is configured on the server (checkcaptcha_required in widget-config). Secret pairs are exempt:
- HTTP:
X-Captcha-Token: <token>header - WebSocket:
captcha_tokenfield on the chat frame
captcha_required / captcha_failed errors.
Rate limits
Client keys can carry an optionalrate_limit_per_min (set at creation). 0 or unset applies the deployment default of 600/min; a negative value means unlimited. Requests over the limit receive 429 with X-RateLimit-Limit / X-RateLimit-Remaining headers; on WebSocket, an {"type":"error","code":"rate_limited"} frame.
Group permissions
Client keys can carryallowed_groups: [uuid] restricting retrieval to specific source groups. Any request group_ids are intersected with this set — a request referencing a group outside the key’s allowed set or outside the knowledge base is rejected with 403.