API keys
Create workspace-scoped keys for Openstead API automation and revoke access when it is no longer needed.
API keys authenticate scripts, SDK clients, and other server-side automation. Each key belongs to your account and one workspace, with a read-only or read-and-write scope.
See API authentication for request headers and API overview for the supported API surface.
Create a key
- Open Account → API Keys in the dashboard.
- Select Create API key.
- Give it a specific name, such as
production-deploy-ci. - Select the workspace and choose read-only or read-and-write access.
- Choose an expiry and create the key.
- Copy the complete key immediately into your secrets manager.
The full key is shown once. The list later displays a prefix, scope, expiry, and last-used time, not the secret value. If you lose the key, create a replacement and revoke the old one.
Keys can have an expiry from 1 to 365 days. Choose the shortest practical lifetime and schedule rotation in your own operational process.
Understand scope and role
| Scope | Intended use |
|---|---|
| Read only | Read supported workspace resources |
| Read & write | Read and change supported resources within your role |
A read-and-write key does not make its creator an admin. Protected environments and operation-specific roles still apply. Viewers can create only read-only keys.
Access also depends on current account status, verified email, workspace membership, and any workspace two-factor requirement. Revoked or expired access cannot be bypassed with a previously created key.
Store keys securely
Use your CI system's secret store or a server-side environment variable such as OPENSTEAD_API_KEY. Keep keys out of source control, browser bundles, analytics, logs, and issue descriptions.
Create different keys for unrelated automation. A descriptive name and narrow scope make revocation easier when a workflow or integration is retired.
API keys are for the supported API. Browser-only payment actions and phpMyAdmin handoffs require an authenticated dashboard session.
Rotate or revoke
To rotate, create a replacement, update the consuming application or CI secret, verify the new key works, and revoke the old key. Keep any overlap as short as practical.
Use the revoke action beside the key in API Keys. Requests using it immediately lose access. Remove the old value from the external secret store as well.
Troubleshooting
An authentication error can indicate a missing, malformed, expired, or revoked key. A permission error can indicate insufficient scope, a role restriction, a protected environment, or a workspace security requirement.
Check the structured API error before creating new credentials. Avoid repeated retries for a permanent permission failure. When asking support for help, share the key's display name or prefix and request ID, never the complete key.