Public access
Look up public-key scope, propagation, headers, and errors.
Public routes may be open or require a product public key. A public key authorizes the selected keyed routes of one product; it does not sign a caller in to the platform or grant organization-management access.
Product owners and admins manage these keys under Public Access in the product’s settings. Other roles cannot open that section.
Key lifecycle
Action | Behavior |
|---|---|
Create public key | Choose a name and scope. New values start with lpk_ followed by 32 hexadecimal characters. |
Copy | Plaintext appears once after creation. It cannot be recovered later. |
List | Shows name, masked key prefix, toolkits, creation date, and Active or Revoked status. |
Edit scope | Replaces the scope without changing the key’s value. |
Revoke | Permanent; the key remains listed as Revoked and cannot be reactivated. Repeating revocation changes nothing. |
Replace a lost key | Create a replacement, update callers, verify it, then revoke the old key. There is no rotate operation. |
Creation, scope edits, and revocation take about 30 seconds to propagate. Wait through that window before checking a new key or testing revocation.
Scope
Setting | Access granted |
|---|---|
All toolkits | All keyed public routes for the product, including ones added later. |
Selected toolkits | Every keyed route of the selected toolkits. |
Individual-route scope through the management API | Only the specified routes; the UI labels it as limited to specific routes. |
Editing a route-limited key in the UI saves a toolkit-level scope and can widen access. The editor warns before saving. Prefer selected toolkits over all toolkits when giving a key to another party.
Request headers
Use Authorization: Bearer for new integrations. The supported order is:
Priority | Header |
|---|---|
1 | Authorization: Bearer <key> |
2 | X-Public-Key: <key> |
3 | X-Api-Key: <key>, a supported legacy alias. |
The first present supported header wins. An invalid higher-priority key does not fall back to a lower-priority one. An Authorization header using another scheme is ignored. All three credential headers are removed before the public handler receives the request.
Open routes require no key. CORS rules, body limits, and rate limits still apply to both open and keyed routes.
Errors
HTTP status | Code | Meaning |
|---|---|---|
401 | public_key_required | No key supplied. |
401 | public_key_invalid | No active key matches for this product, including a revoked key after propagation. |
403 | public_key_scope | The key does not cover this route. |
503 | public_config_unavailable | Public-key configuration is not loaded yet; retry later. |
An unknown route (404), oversized body (413), or rate limit (429) is not a key-scope error.
Imported keys
Older Realtime, Mail, and Tracking keys may appear with an Imported badge. They keep their original values and prefixes, such as rtk_, lmk_, or sk_live_; importing does not convert them to lpk_.
Their scope covers the keyed routes of their original toolkit. Any finer permissions held by that toolkit did not carry over. Owners and admins can now change their scope or revoke them like other public keys. Imported values are not revealed in the list.
Existing callers using one of the three supported headers can keep it. A caller using a different custom header must change to a supported one. Imported keys retain their name and creation date, with an imported-name fallback when no name existed.