API: Projects — group resources, scope credentials, and attribute spend

The /v1/projects endpoints are now in the public API reference. A project groups the resources you create inside a workspace and the spend you incur from them, so one workspace can run several environments or several end customers without splitting into separate accounts.

Every workspace has an implicit Default project: any resource with no project lives there, and nothing you already send changes — the surface is additive and opt-in.

What a project groups:

Kind	Belongs to a project
Agents, knowledge bases, tools, audio assets	Yes, and can be moved later
Phone numbers and SIP trunks	Yes
API keys and service accounts	Yes — a pin fixed when the credential is created
Vault credentials and webhook endpoints	One project, or workspace-wide
Conversations, callers, batch calls, test runs, memories	Yes, frozen at creation and never re-attributed
Usage and spend	Attributed through the calling credential’s pin
Cloned voices	From the pin on the creating credential — except a consent-verified clone, which is always workspace-wide
The public voice and model catalog	No — workspace-wide

Manage the lifecycle with POST/GET/PATCH/DELETE /v1/projects and .../{project_id}, plus archive, unarchive, restore, teardown, stats, audit, promote, and the members sub-tree (grant/revoke access). Move an existing agent with POST /v1/agents/{agent_id}/move.

Filtering: every list endpoint that takes a project accepts a project_id query parameter. Omit it to get everything you can reach, pass a proj_... id for one project, or pass the literal default for the implicit Default project. On lists whose rows can be workspace-wide — credentials, webhook endpoints and cloned voices — that literal is shared instead, because an absent project there means workspace-wide rather than Default.

Names are unique per workspace, case-insensitively; a workspace holds at most 100 live projects, and at the cap the create is refused with 409 project_limit_reached.

A project is a filter and a grouping, not a security boundary — it scopes what a credential may reach, what a scoped member sees, and where spend lands. If one team must be unable to see another’s data at all, use a separate workspace. See Projects.