Skip to content
Go to Boltz API

Organizations & Workspaces

How organizations, workspaces, and API keys are structured in the Boltz API.

Organization (created during onboarding)
├── Admin API Key (org-level)
└── Workspaces
├── Default Workspace (implicit, always exists)
├── Workspace "Customer A"
├── Workspace "Team Alpha"
└── ...
└── Workspace API Key(s)

An organization is the top-level entity, created during onboarding. It is read-only via the API.

A workspace is an isolated environment with its own API keys and usage tracking. All resources (predictions, design runs, library screens) belong to a workspace. Every organization has a default workspace that always exists.

Admin keys are organization-scoped. For job endpoints that accept workspace_id, an admin key can target any non-archived workspace in the organization. If workspace_id is omitted, the request uses the default workspace.

If you’re building a platform that exposes Boltz capabilities to your own customers, create one workspace per downstream customer. Each customer gets their own workspace API key, providing isolation and per-customer usage tracking.

If you’re using Boltz across multiple teams, create workspaces for internal teams or projects. Admin keys manage the workspace lifecycle and can run jobs across all workspaces in the organization, while team members use workspace keys for jobs within a single workspace.

If you’re a single researcher, using the default workspace with your admin key is the simplest setup. No additional workspace setup is needed.

Usage and costs are tracked per workspace, per API key, and per resource type. Admin keys can query usage data across the organization with hourly or daily granularity.