Projects
By default, a generation created from the API isn’t filed under anything in particular. Projects let you group related generations and assets together so they appear under one project in the Studio — and so you can list them back out from the API. It’s a two-way road: create a project from the API, attach work to it, and it’s visible in the Studio UI; create a project in Studio, and the API can attach to it too.
A project is lightweight — only a name is required.
Create a project
POST /v2/projects returns the new project’s id. visibility defaults to USER (visible only to the key owner) and mode to CREATOR; both are optional.
Attach generations and assets
Pass the project’s id as projectId when you create a generation or register an asset. The field is optional on both endpoints — omit it and the work simply isn’t grouped under a project.
The generation and asset responses echo back the projectId they were filed under (or null when none was given).
projectId must reference a project in your organization. If it doesn’t (wrong id, or a project from another org), the create request is rejected with 422 Unprocessable Entity — the generation or asset is not created. A missing or null projectId is always fine.
See it in Studio
Once attached, generations and assets show up under the project in the Studio. This works in both directions — a project you create in Studio can be targeted from the API by its id, and a project you create from the API appears in Studio. Deleting a project does not delete the generations or assets that were attached to it; they simply stop being grouped under it.
Manage projects
GET /v2/projects is cursor-paginated (limit, cursor) and supports searchQuery (by name) and sortBy (updatedAt or name). PATCH only changes the fields you send.

