Workspace features overview

Workspace features are the switches that decide which parts of Plane are available in a workspace. The resource is a single object with one GET and one PATCH. Read it before anything else, because two of its fields change how the rest of the API behaves.

The most important one is is_work_item_types_enabled. It sets the work item type mode: whether the workspace or each project owns types and their properties, and therefore which endpoints accept your writes. Writing to the wrong surface returns 409, not 404 or 403.

The workspace feature object

Attributes

• id string (uuid)

  Unique identifier for the workspace's feature record.

• is_work_item_types_enabled boolean

  Whether work item types are managed at the workspace level. true means workspace mode: types and properties are defined once for the workspace and imported into projects. false means project mode: each project owns its own types. This is the field to read before any type or property write. See Work item type modes.

• work_item_type_default_level integer

  The default level applied to work item types in this workspace. The schema constrains it to an integer and declares no enum, so treat any value as valid and leave it as returned unless you mean to change type levels.

• is_workitem_hierarchy_enabled boolean

  Whether work items can be nested into a parent and child hierarchy in this workspace.

• is_project_grouping_enabled boolean

  Whether projects can be organized into groups in the workspace.

• is_teams_enabled boolean

  Whether teamspaces are available. Teamspaces have their own endpoints under the teamspaces:* scopes.

• is_wiki_enabled boolean

  Whether the workspace-level wiki is available, behind the wiki.pages:* scopes.

• is_initiative_enabled boolean

  Whether initiatives are available. Initiatives group projects and epics toward a larger outcome.

• is_customer_enabled boolean

  Whether customers and customer requests are available, behind the customers:* scopes.

• is_release_enabled boolean

  Whether releases are available, behind the releases:* scopes.

• is_state_duration_enabled boolean

  Whether Plane records how long work items spend in each state.

• is_pi_enabled boolean

  Whether Pi, Plane's AI assistant, is available in the workspace.

• created_at string (date-time)

  When the feature record was created.

Watch the spelling of the hierarchy flag

It is is_workitem_hierarchy_enabled, with no underscore between work and item, while its neighbor is is_work_item_types_enabled. Unknown keys in a PATCH body do not toggle anything, so a misspelled key changes nothing and raises no error. Read the response and confirm the flag changed.

Response200

{
  "id": "a72f1c40-5b8e-4d19-9f2a-3c6d8e1b7a55",
  "is_work_item_types_enabled": true,
  "work_item_type_default_level": 0,
  "is_workitem_hierarchy_enabled": false,
  "is_project_grouping_enabled": false,
  "is_teams_enabled": true,
  "is_wiki_enabled": true,
  "is_initiative_enabled": false,
  "is_customer_enabled": false,
  "is_release_enabled": false,
  "is_state_duration_enabled": false,
  "is_pi_enabled": false,
  "created_at": "2026-01-14T09:22:41.478363Z"
}

Endpoints

Method	Path	Description
GET	/api/v2/workspaces/{slug}/features/	Get workspace features
PATCH	/api/v2/workspaces/{slug}/features/	Update workspace features

There is one feature record per workspace, so the path has no id and there is nothing to create or delete.

Discovering the work item type mode

A workspace manages work item types in exactly one mode, and this endpoint is how a client finds out which:

curl "https://api.plane.so/api/v2/workspaces/my-team/features/" \
  -H "X-Api-Key: $PLANE_API_KEY"

• is_work_item_types_enabled: true means workspace mode. Type and property writes go to /api/v2/workspaces/{slug}/work-item-types/ and the related workspace endpoints. The project-level equivalents return 409 work_item_types_managed_at_workspace.
• is_work_item_types_enabled: false means project mode. Those writes go to /api/v2/workspaces/{slug}/projects/{project_id}/work-item-types/. The workspace-level equivalents return 409 work_item_types_managed_at_project.

Reads are not affected by mode. A project lists its types in either mode, so a read-only integration never has to branch. Only writes depend on the mode.

For a full walkthrough, including how each surface differs, see Work item type modes.

Read the mode, do not guess it

If you branch on a 409 from an earlier call, your client keeps acting on an old configuration. Read is_work_item_types_enabled, cache it briefly, and re-read it when a write returns 409, because an admin may have switched the mode between your calls.

Flags change what other endpoints do

Turning a flag off removes the capability from the workspace, so calls that depend on it stop being useful even if their routes still respond. Design for two consequences:

• Toggling is_work_item_types_enabled moves the write surface for every client in the workspace, not only yours. Treat it as an administrative action, not something an integration changes at runtime.
• A flag set to true is not enough on its own. The feature also has to be available on the workspace's plan. Treat a successful call, not the flag alone, as proof that a capability is available.

Scopes

Operation	Scope
GET	workspaces.features:read
PATCH	workspaces.features:write

Changed from v1

• Flags are now prefixed and suffixed consistently: v1's project_grouping, initiatives, teams, customers, wiki, and pi are is_project_grouping_enabled, is_initiative_enabled, is_teams_enabled, is_customer_enabled, is_wiki_enabled, and is_pi_enabled.
• New in v2: is_work_item_types_enabled, work_item_type_default_level, is_workitem_hierarchy_enabled, is_release_enabled, and is_state_duration_enabled.
• The response now carries id and created_at alongside the flags.

See Migrating from v1 for the full list.

Related

• Get workspace features
• Update workspace features
• Work item type modes