API keys & authentication
Use the minimum access needed for your integration.
Create and store a key
Create API keys in Integration & API in the panel. A key belongs to its owner and is subject to that account’s access and plan limits. Copy it when it is created and store it securely; the server stores a hash rather than the original key.
Bearer authentication
Authorization: Bearer upk_YOUR_KEYUse HTTPS and send the key in the header. Do not put it in query strings, public pages or client-side bundles. Browser sessions can take precedence over bearer authentication, so use a script or separate client when testing a key’s scope.
Read and write scopes
| Scope | Intended use | Behavior |
|---|---|---|
| Read | Reporting and dashboards | Read operations such as GET; write operations return 403. |
| Write | Management workflows | Allows writes only where ownership, feature access and permissions also allow them. |
A write scope does not bypass plan limits, resource ownership or operation-specific restrictions. A revoked key stops authenticating; a key disabled by the plan can return a permission error.
Other credential types
| Credential | Purpose |
|---|---|
upk_… | Workspace REST API requests. |
upl_… | Application-log ingestion only. |
uph_… | Metrics ingestion for one host. |
| Secret heartbeat URL | Signal completion or failure of one scheduled job. |
Rotation and revocation
Create a replacement key, update the integration and verify a successful request before revoking the old key. If a key is exposed, revoke it promptly and inspect the actions performed with the affected integration. Never send a real key in a support ticket.
Workspace context
The public contract includes selected workspace endpoints, but not all workspace operations accept API keys. Operation-specific permissions and session restrictions still apply. Do not assume an API key inherits an interactive browser workspace switch.