enabled state and percentage rollout, then individual
workspaces may attach an override row that flips the flag for that workspace
only.
All endpoints require authentication and workspace context. Reads are open to
any workspace role; mutations (flag definition CRUD and per-workspace override
CRUD) require OWNER or ADMIN.
List Feature Flags
key ascending. When the request
carries workspace context, each flag includes the current workspace’s
override state (override_enabled), or null/omitted when no override row
exists for that flag.
Auth: Any authenticated workspace member (read)
Response: 200 OK
Response Fields
Create Feature Flag
OWNER or ADMIN role
Request Body:
201 Created — the created flag object (same shape as a List item, without override_enabled).
WebSocket event:
feature_flag.created
Update Feature Flag
OWNER or ADMIN role
Request Body: All fields optional.
Response:
200 OK — the updated flag object, including override_enabled for the current workspace (same shape as a List item).
WebSocket event:
feature_flag.updated
Delete Feature Flag
ON DELETE CASCADE on the override table
means all per-workspace override rows are removed too.
Auth: OWNER or ADMIN role
Response: 204 No Content
WebSocket event:
feature_flag.deleted
Set Workspace Override
PUT with the same body updates the same row in
place (keyed on UNIQUE(flag_id, workspace_id)).
Auth: OWNER or ADMIN role
Request Body:
200 OK
WebSocket event:
feature_flag.override_set
Clear Workspace Override
204 whether or
not an override row existed (after this call, the override does not exist).
Auth: OWNER or ADMIN role
Response: 204 No Content
WebSocket event:
feature_flag.override_cleared (only when a row was actually removed)