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 meant 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 limited to 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. Only status carries the extra locked group layer, though, and status is 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. Once the workflow itself needs to change, the API mostly goes read-only:

• Renaming "In review" to "Client review", the most common board edit of all, 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 to open each database in the UI.

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

The 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. Renaming or recoloring an existing select option is just as impossible, though.
• 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 is a paginated read-modify-write over every card in the board, so it runs straight into the 3 requests/second average. Budget minutes rather than seconds for large boards.

NovumOS is a kanban board, so columns are their own REST resource with full CRUD instead of a property schema bolted onto a database. 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 you define your board’s top-level phases instead of living with a fixed set of three. Column edits broadcast on the realtime channel like any other mutation, so a rename an agent makes shows up in every open browser. We made this choice on purpose: editable status options are one of the four API fixes in the product’s spec (§7.4), because the locked-down version is a non-starter for a kanban app.