Project

Type Schema name Project, addressed at /entity/projects. Site-wide, not project-scoped.

The path segment is matched against the schema name loosely. Both cases and both numbers resolve; what 404s is a spelling that loses the word boundary, and the 404 names the type it could not find.

Probe 002 found no endpoint that enumerates types, so write the snake_case plural and treat the 404 detail as the check.

Project has no project field, so nothing scopes a listing of projects:

GET /entity/projects?filter[project.Project.id]=N -> 400
  title  "API read() Project.project.Project.id doesn't exist."
  source {"Project.project.Project.id": " does not exist. Value: {\"path\" => \"project.Project.id\",
          \"relation\" => \"is\", \"values\" => [\"N\"]}"}

Narrow a project listing with filter[id] or with the checkboxes (probe 018). Project is the scope every other type points at, so the useful direction is inbound:

Identity name. It is the only field on the type flagged both mandatory and unique, and it is what cached_display_name mirrors.

code is not the identity here, unlike Shot.code and Version.code. It is unique when set and may be empty: on the probed site 5 of 22 projects have a code, and it equals name on 1 of them. tank_name is the folder name on disk, not a display name. Read name, and cached_display_name only as a fallback.

Create POST /entity/projects with {"name": ...} and Content-Type: application/json returns 201 (probe 011, behind --write). The 201 body echoes 6 attributes, not the row, so GET the new project for anything else. name being unique means a create is not idempotent: search by name first and reuse the hit. This card posts nothing. Project is site-wide, so there is no sandbox project to scope a write to, and every row is a real show.

Links

All of them are returned under relationships, never attributes (field_types/entity, field_types/multi_entity). A client normally reads none of them: it identifies a project and then filters other types by it. layout_project names the template a project was cloned from and is read only. phases declares no valid_types at all, so validate that one client-side.

Status sg_status, data_type list rather than status_list. There is no Status row behind a list, so there is no icon, no bg_color and no display label to render (field_types/status_list, probe 010). Read the usable set for one project with GET /schema/Project/fields?project_id=N and subtract hidden_values from valid_values (probe 009); the vocabulary itself is site configuration. sg_type is a second list field of the same shape.

On the probed site sg_status has no display_values and is null on 15 of 22 projects, 8 of them working shows, so a picker that filters on it hides real projects (probe 018).

Traps

• is_template, is_demo and is_template_project are read only over REST, so the flags a picker filters on cannot be set by a script user. archived is editable.
• start_date, end_date and duration are read only and derived. On the probed site all three are null on every project read, so do not filter or sort a project listing on them.
• landing_page_url is a path, not a URL: "/detail/Project/N?legacy=true". Prefix the site URL yourself.
• On the probed site GET /schema/Project/fields returns 42 fields, 15 of them not editable (created_at, created_by, duration, end_date, id, image_blur_hash, image_source_entity, is_demo, is_template, is_template_project, landing_page_url, layout_project, start_date, updated_at, updated_by). The count is site configuration; the names are stock.