API Keys
Daytona API keys authenticate requests to the Daytona API. They are used by the Daytona SDKs and CLI to access and manage resources in your organization. An API key belongs to one organization and carries a set of permissions. See authentication for how the SDKs, CLI, and API read the key.
Create an API key
Section titled “Create an API key”Create API keys to authenticate Daytona SDKs, API, and CLI requests.
- Go to Daytona Dashboard ↗
- Click
- Enter the name of the API key, set the expiration date, and select permissions
- Click
- Copy the API key to your clipboard and use it to authenticate requests
Permissions & Scopes
Section titled “Permissions & Scopes”Permissions govern the resources in your organization — creating, modifying and deleting sandboxes, snapshots, registries, volumes, regions, runners and keys. Read access to sandboxes, snapshots, registries and regions is always granted and cannot be withheld.
Any member of an organization can create an API key for themselves; key creation is not itself a grantable assignment. A key cannot be created with permissions beyond those its creator holds — a request that includes any scope outside the creator’s own assignments is rejected outright rather than trimmed. A member with no assignments can therefore only create a key with no permissions. manage:api_keys governs creating keys with an API key rather than interactively.
Sandbox runtime access is not a grantable scope. Any API key valid for an organization can address that organization’s running sandboxes through the toolbox — running processes, reading and writing files, opening preview URLs and using the terminal — regardless of the permissions selected for the key, including a key created with none. The organization is the trust boundary for sandbox compute; the scopes below control the resources themselves, not what runs inside them.
Organization usage and spend data is a partial exception. The endpoints that serve usage and cost accept read:billing, and also accept write:sandboxes for compatibility with keys provisioned before read:billing existed. A key that can create sandboxes can therefore also read what those sandboxes cost. Interactive sessions are unaffected — a member’s role must grant read:billing to view spending in the dashboard.
A sandbox’s deletion schedule is a modification rather than a deletion. Setting the auto-delete interval or the time-to-live on an existing sandbox requires write:sandboxes, and both values are also accepted when a sandbox is created. When either schedule elapses the sandbox is destroyed and its local filesystem is not recoverable, so a key holding write:sandboxes alone can cause sandboxes to be deleted on a schedule. delete:sandboxes governs the explicit delete request.
Secrets are mounted into sandboxes by name, so write:sandboxes also governs which secrets a sandbox receives. A key holding write:sandboxes can mount any secret in the organization without holding manage:secrets. A secret with no host allowlist is substituted into requests to any host, so such a key can obtain that secret’s value. Set a host allowlist on every secret.
Creating a snapshot from an existing sandbox requires write:sandboxes rather than write:snapshots. The result is an organization snapshot like any other: it is listed with the organization’s snapshots, other members can create sandboxes from it, it counts against the organization’s snapshot quota, and it persists after the source sandbox is deleted. delete:snapshots governs its removal.
| Resource | Scope | Description |
|---|---|---|
| Sandboxes | write:sandboxes | Create/modify sandboxes, including the deletion schedule and snapshots created from a sandbox |
delete:sandboxes | Delete sandboxes | |
| Snapshots | write:snapshots | Create/modify snapshots |
delete:snapshots | Delete snapshots | |
| Registries | write:registries | Create/modify registries |
delete:registries | Delete registries | |
| Volumes | read:volumes | View volumes |
write:volumes | Create/modify volumes | |
delete:volumes | Delete volumes | |
| Audit | read:audit_logs | View audit logs |
| Regions | write:regions | Create/modify regions |
delete:regions | Delete regions | |
| Runners | read:runners | View runners |
write:runners | Create/modify runners | |
delete:runners | Delete runners | |
| API Keys | manage:api_keys | Create, list, and delete API keys using an API key |
| Secrets | manage:secrets | Create, update, and delete secrets |
| SSO | manage:sso | Generate Admin Portal links, list SSO connections, and manage legacy identity providers for organization SSO |
| Limits | read:limits | View organization limits and quota usage |
| Billing | read:billing | View organization usage, spend, wallet, and invoices |
manage:billing | Manage billing settings and payment methods |
List API keys
Section titled “List API keys”List API keys for the current user or organization.
When authenticated with a JWT, organization owners see all keys in the organization and other users see only their own keys. When authenticated with a manager API key, the response is limited to keys that manager key created. See Managed API keys.
curl 'https://app.daytona.io/api/api-keys' \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_JWT_TOKEN'Get current API key
Section titled “Get current API key”Get details of the API key used to authenticate the current request.
curl 'https://app.daytona.io/api/api-keys/current' \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_API_KEY'Get API key
Section titled “Get API key”Get a single API key by name.
curl 'https://app.daytona.io/api/api-keys/my-api-key' \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_JWT_TOKEN'Delete API key
Section titled “Delete API key”Delete an API key.
The key is revoked immediately and cannot be recovered.
- Go to Daytona Dashboard ↗
- Click next to the API key you want to delete
- Confirm the revocation
curl 'https://app.daytona.io/api/api-keys/my-api-key' \ --request DELETE \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_JWT_TOKEN'Delete API key for user
Section titled “Delete API key for user”Delete an API key for a specific user.
This endpoint requires JWT authentication and is available to the key or organization owner.
curl 'https://app.daytona.io/api/api-keys/{userId}/my-api-key' \ --request DELETE \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_JWT_TOKEN'Managed API keys
Section titled “Managed API keys”Contact Daytona to enable this feature for your organization.
Daytona provides Managed API keys to create and manage API keys programmatically. Managed API keys let a manager key mint, list, and delete child API keys without a JWT session.
A manager key is an API key with the manage:api_keys permission. Use this when an application or service needs to issue scoped keys to tenants or workloads at runtime.
When authenticated with a manager key:
- child key permissions must be a subset of the manager key’s permissions
- a manager key can only list and delete keys it created; it cannot access other keys
- child keys cannot manage other keys unless you explicitly grant them
manage:api_keys
Create a manager key
Section titled “Create a manager key”Create a manager key.
- Go to Daytona Dashboard ↗
- Click
- Enter the key name, set the expiration date, and enable Manage API keys
- Select the resource scopes child keys may use
- Click
- Copy the API key to your clipboard
curl 'https://app.daytona.io/api/api-keys' \ --request POST \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer YOUR_JWT_TOKEN' \ --data '{ "name": "Manager Key", "permissions": ["manage:api_keys", "write:sandboxes", "delete:sandboxes"]}'Create a child key
Section titled “Create a child key”Create a child key.
curl 'https://app.daytona.io/api/api-keys' \ --request POST \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer YOUR_MANAGER_API_KEY' \ --data '{ "name": "tenant-a-key", "permissions": ["write:sandboxes", "delete:sandboxes"]}'The response includes the full child key value. Store it immediately. After creation, only a masked value is available when listing keys.
List child keys
Section titled “List child keys”List child keys.
curl 'https://app.daytona.io/api/api-keys' \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_MANAGER_API_KEY'Delete a child key
Section titled “Delete a child key”Delete a child key.
-
Authenticate with the manager key
-
Send a
DELETErequest to/api-keys/{name}A manager key can only delete keys it created
curl 'https://app.daytona.io/api/api-keys/tenant-a-key' \ --request DELETE \ --header 'X-Daytona-Organization-ID: YOUR_ORGANIZATION_ID' \ --header 'Authorization: Bearer YOUR_MANAGER_API_KEY'