Organizations & Workspaces
How organizations, workspaces, and API keys are structured in the Boltz API.
Organization hierarchy
Section titled “Organization hierarchy”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.
Common patterns
Section titled “Common patterns”Platform (B2B2C)
Section titled “Platform (B2B2C)”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.
Enterprise
Section titled “Enterprise”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.
Individual researcher
Section titled “Individual researcher”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 tracking
Section titled “Usage tracking”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.