Keys and workspace access
Authentication identifies your account. App enablement and key permissions determine what an integration can use.
| Key | Access | Use case |
|---|---|---|
| App key | One enabled app | A service-specific project |
| Global key | All enabled apps, including future activations | A trusted multi-product backend |
Create keys where you work
Use App keys inside each service. The central API keys page also creates global keys. Secrets are shown once; only hashes are stored. Disabling an app blocks both key types.
Workspace roles
Owner and Admin manage members, app activation and all workspace keys. Developer can use enabled services and manage only keys they created. Viewer has read-only access. An invitation must be accepted by its verified email recipient. Role changes and removal revoke that member's keys.
Protect your credentials
- Use environment variables or a secret manager.
- Never put keys in URLs, frontend bundles or logs.
- Separate development and production keys.
- Rotate by deploying a new key, verifying it, then revoking the old one.
- Password changes invalidate your sessions and keys you created across workspaces. Other members' keys stay active.
Service separation
Hosted services have distinct server credentials and authorize only their own product. These credentials are different from customer global keys. Authorization fails closed when the central authority is unavailable.
Ready to build?
Your apps, keys and setup in one workspace.