Definitions

Definitions are the building blocks you reference on a task or event: its status, its type, and (for projects) the project’s own status. You read a definition to get its id, then pass that id when you create or update a resource — e.g. task_status_id on a task, event_type_id on an event.

Where definitions come from

Definitions are created at the workspace level and linked into individual projects through project settings in the Bordio web app (not over the API). So there are two views:

Workspace catalog — the full set defined in the workspace. GET without a filter.
Project view — the subset linked to one project. GET with ?project_id=proj_....

A definition must be available in a task’s project to be used on that task, so the project view is your source of truth for “what can I set here”. This is the same linking model as custom fields.

Resources

All four live under /public/v1 and return a data array.

Endpoint	Item shape	`?project_id`	Used on write as
`GET /task_statuses`	`{ id, name, state }`	✅	`task_status_id`
`GET /task_types`	`{ id, name }`	✅	`task_type_id`
`GET /event_types`	`{ id, name }`	✅	`event_type_id`
`GET /project_statuses`	`{ id, name, state }`	❌ workspace-only	(on projects)

state (on statuses) is either open or closed.

Statuses (with state)

curl "https://api.bordio.com/public/v1/task_statuses?project_id=proj_6594a1b2c3d4e5f6a7b8c9a0" \
  -H "Authorization: Bearer brd_sk_live_..."

{
  "data": [
    { "id": "task_status_6594a1b2c3d4e5f6a7b8c9d0", "name": "To do", "state": "open" },
    { "id": "task_status_6594a1b2c3d4e5f6a7b8c9d1", "name": "In progress", "state": "open" },
    { "id": "task_status_6594a1b2c3d4e5f6a7b8c9d2", "name": "Done", "state": "closed" }
  ]
}

Types (name only)

// GET /task_types
{
  "data": [
    { "id": "task_type_6594a1b2c3d4e5f6a7b8c9e0", "name": "Bug" },
    { "id": "task_type_6594a1b2c3d4e5f6a7b8c9e1", "name": "Feature" }
  ]
}

event_types has the same shape, with event_type_ ids.

Using an id on write

curl -X PATCH https://api.bordio.com/public/v1/tasks/task_6594a1b2c3d4e5f6a7b8c9f0 \
  -H "Authorization: Bearer brd_sk_live_..." \
  -H "Content-Type: application/json" \
  -d '{ "task_status_id": "task_status_6594a1b2c3d4e5f6a7b8c9d2" }'

Scoping rules

No project_id → the full workspace catalog.
?project_id=proj_... → only the definitions linked to that project.
Project-scoped key → always limited to its own project: a foreign project_id returns 404 not_found_error, and no filter returns that project’s subset.
project_statuses is workspace-only — passing ?project_id returns 422 validation_error (invalid_request). These are the statuses a project itself can be in (each with state), not statuses within a project.

Priorities

Task priority is not a definitions resource — it’s a fixed set carried inline on the task priority field:

lowest · low · medium · high · critical

Custom fields

Custom fields are a richer definitions-like resource with their own value formats — see Custom fields.