---
title: Organizations & Workspaces | Boltz API Docs
description: How organizations, workspaces, and API keys are structured in the Boltz API.
---

## 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

### 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

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

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

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.