Keys and authentication
Keep public ingestion, secret build uploads, and agent sessions separate.
Which credential goes where?
| Credential | Used for | Browser bundle? |
|---|---|---|
Public project key pk_… | SDK telemetry and public release reports | Yes |
Secret upload key ik_… | Source-map upload in CI/server builds | Never |
| CLI/device session | Authenticated agent and platform operations | Never |
| Personal API key | Explicit CI/platform integration where supported | Never |
| GitHub App/OAuth secrets | Authorized repository integration on the server | Never |
A public ingestion key is not a platform management token. CLI login does not turn it into a secret account credential and does not grant GitHub access.
Rotation
Project key endpoints support rotation. Update the consuming runtimes/build environment with the new value and verify delivery. Do not keep using predictable legacy project-ID-derived keys; new integrations should use the generated random key.
Storage
Keep CLI credentials in their protected configuration directory and server/provider secrets in a secret manager or private files. Never put an ik_… upload key, a personal API key, an OAuth client secret, or a private App key into a browser variable.
For self-hosting, set the deployment's public origins and encryption/authentication configuration consistently. A local-development service token is not an appropriate universal public-user credential.