API key scopes: read, write, and build

Every developer API key carries scopes that define what it is allowed to do. Scopes keep keys least-privileged: a read-only integration shouldn't be able to spend credits, and a build agent shouldn't have more reach than it needs.

The public-facing scopes

The scopes advertised for developer keys are read, write, and build. A new key is created with all three by default (read, write, build).

• read — list and fetch your data (for example, listing projects, flow templates, build status, or artifacts).
• write — create or modify data (for example, creating a project or writing artifacts).
• build — run operations that consume credits, such as starting a build, generating CAD, or running a flow. Build is the scope tied to spending.

How scopes are enforced

Every API and MCP handler authenticates the key first, resolves your tenant, and then checks the scope required for that specific operation. On the MCP server, a tool that needs a scope your key lacks returns a forbidden error (JSON-RPC code -32001). On the REST API, the operation is rejected.

Choosing scopes

Give each key only what it needs. A monitoring script that just reads status can use a read-only key. An autonomous agent that generates CAD or runs flows needs build. Because build spends credits, be deliberate about which keys carry it.

Note on internal scopes

The system also recognizes additional scopes (integrations and admin, where admin implies all), but the scopes surfaced for developer keys are read, write, and build.