Editable status options: where Notion’s API stops

This limitation used to be absolute. Notion’s own API changelog (entry of March 19, 2026) says it plainly: “Previously, status properties were read-only — they could be queried but not created or modified via the API.” That is years of kanban integrations — where status is the board — unable to touch the one property they were built around. The March 2026 change added creation (with default options Not started / In progress / Done, or custom initial options) and the ability to add options to an existing status property.

From Notion’s update-data-source-properties reference and the property schema reference, the status property’s API surface is:

• Add an option — yes. New options can be created and assigned to one of the existing groups.
• Remove an option — yes, but the value is cleared from every page that used it. There is no migrate-then-remove primitive.
• Rename or recolor an existing option — no. “The name and color of an existing option cannot be updated.”
• Create, rename, or reorder groups — no. The group field’s documented values are exactly To-do, In progress, and Complete; “to rename, reorder, or otherwise reconfigure groups, use the Notion UI.”

The same rename/recolor restriction applies to select and multi_select options — but only status carries the extra locked group layer, and status is exactly the property a board’s columns hang off.

Everything a workflow tool does to a board eventually touches its columns. On Notion, an integration or AI agent can move cards between statuses all day — but the moment the workflow itself needs to change, the API mostly goes read-only:

• Renaming "In review" to "Client review" — the single most common board edit — cannot be done programmatically. The remove-and-re-add trick wipes the status off every card that had it.
• A pipeline with more than three top-level phases cannot exist: status groups are hard-capped at To-do / In progress / Complete, and no API call adds a fourth.
• A provisioning script that stamps out one board per client cannot fully converge the schema — option colors and group structure still require someone opening each database in the UI.

This is a limitation people find the hard way, usually mid-build. A few verified public examples:

Honest options, roughly in order of least pain:

• Model workflow state as a select property: no group layer to get stuck on, and options can be added via API — though renaming or recoloring an existing select option is equally impossible.
• Treat status as configure-once: set up options and groups by hand in the UI, and never let automation depend on changing them.
• Template databases: keep a master database whose status property is pre-configured, and duplicate it instead of building schemas via API.
• For a true rename, do it in the UI. If it must be API-driven, add the new option, migrate every page’s value with per-page PATCHes (mind the rate limit), then remove the old option.

That last one — a paginated read-modify-write over every card in the board — runs straight into the 3 requests/second average, so budget minutes, not seconds, for large boards.

Novum OS is a kanban board, so columns are not a property schema bolted onto a database — they are their own REST resource with full CRUD, and the same operations exist as typed MCP tools (create_column, update_column, delete_column) so an agent teammate can restructure a workflow directly:

PATCH /v1/boards/{board_id}/columns/{column_id}
{
  "name": "Client review",
  "color": "pink"
}

// Create a new lane in an existing status group
POST /v1/boards/{board_id}/columns
{
  "name": "AI Drafting",
  "status_group": "in_progress",
  "color": "yellow"
}

Status groups are editable too — PATCH /v1/boards/{id} accepts a status_groups list, so your board’s top-level phases are yours to define, not a fixed set of three — and column edits broadcast on the realtime channel like any other mutation, so a rename an agent makes shows up in every open browser. This is a design commitment, not an accident: editable status options are one of the four API fixes in the product’s spec (§7.4), precisely because the locked-down version is a non-starter for a kanban app.