Form layout of an object type
GET/property-groups
How the desktop lays out the form of an object type for the caller: its groups ("Details",
"Related to", or the installation's own), each on the left, the right or full width, and
the fields in each — the object's own fields, dimension selectors and custom properties —
in order. Filtered as the form is: what the caller may not see is left out and what they
may only see comes readonly. With subtype, the layout of that subtype's form.
property_groups is null when the installation draws the type's built-in form instead.
Good for drawing forms too: each field says whether the type's create (writable) and
update (updatable) endpoints take it, and as which body keys (api_fields) — the layout
names the object's column, which the body may call otherwise. A field with both false
is shown only. Types the API does not write (tasks, budgeted expenses, invoices) have
every field false.
Only content objects (tasks, time entries, notes, expenses, invoices, …): a dimension
member type such as project is 422 object_type: unsupported. Since 4.3.1.
Request
Responses
- 200
- 401
- 404
- 422
OK
Missing, invalid or expired token, or no contact matches it.
Unknown route, or the resource is missing or in the trash; message names what was
looked for (task, note, payment_receipt, expense…). On an expenses route,
message: "expenses" means the plugin is not active.
details: object_type: required | unsupported, subtype: object_type_mismatch.