The catalog is where you find something to call. An assignment is what lets a project call it. Seeing a product in the catalog and being able to spend on it are two different things — and that separation is the thing most worth understanding on this page.
The catalog#
Every signed-in member of an organization can browse its catalog. It lists published, immutable product versions: products published by the platform, plus products your own organization submitted and had approved — those stay private to your organization. Each entry is a frozen version with frozen pricing, either a flat price per request or separate input and output rates per million tokens.
Browsing is discovery, not access. A product can sit in your catalog, fully priced and described, and still refuse every call until someone assigns it. The catalog entry says whether a product is assigned to any project yet.
Project-private sandbox products never appear in the catalog or in
/v1/models — they belong to one project and are reached through it.
Assigning a product to a project#
An organization Owner or Administrator assigns a product, and the assignment names one exact published version — the version and its price are accepted for that project, once, explicitly. There is no org-wide switch.
Three rules make assignments predictable:
- Assignments are per project, and nothing cascades. Assigning a product to one project does not enrol its team, its members, or any sibling project. The list of projects that can call a product is the list of assignments.
- Unassigning takes effect immediately. The next call is refused. Reservations already held for calls in flight still settle as recorded — a hold is never stranded by a withdrawn assignment.
- The assignment pins the version. If a new version of a product is ever published, an existing assignment does not follow it — moving to the new version is a deliberate reassignment.
/api/v2/tenants/{tenantID}/catalogue/api/v2/tenants/{tenantID}/projects/{projectID}/products/api/v2/tenants/{tenantID}/projects/{projectID}/products/api/v2/tenants/{tenantID}/product-assignments?projectId=Personal workspaces need no assignment#
A personal workspace plays by one exception: its managed project is bound to every callable product visible to the workspace, automatically. There is no assignment step, and the binding cannot be removed. Sign in, fund the wallet, call.
What a caller sees#
When access is missing, the refusal comes back before any money moves:
| Error | Where | Meaning | Fix |
|---|---|---|---|
403 product_not_assigned |
playground | the product is callable in the organization but not assigned to the named project | an Owner or Administrator assigns it |
404 model_not_found |
API key | the id is not eligible for the key's project right now — including a removed assignment | check /v1/models; ask for an assignment |
403 key_scope |
API key | the resource is eligible, but the key's own list excludes it | use a key that lists it |
402 insufficient_budget |
both | the project wallet cannot cover the reservation | top up |
A denied call is never charged. See Usage and metering for what is recorded.
Next#
- Caps and spend controls — bounding what a project may spend
- Usage and metering — seeing what was actually spent