Manage domain values
List a column's allowed values, then add, replace, and remove fixed values and hierarchy parents/children.
Once a domain is set, grow and prune
it with granular value endpoints instead of re-sending the whole configuration.
Two families: values on a fixed domain, and parents/children on an inline
hierarchical domain. All of them require domains:write.
Good to know
id - read them with get_allowed_values (below). Creation endpoints
(add value, add child) take the new value as a string; deletion and parent
endpoints address existing values by id. A CLI argument that already looks like a
UUID is passed through unresolved.List the allowed values
get_allowed_values returns a column's configured domain values - use it to
inspect a domain, and to get the parent UUIDs a
hierarchical mapping keys on:
eddytor get domain-values eddytor sales orders statusGET /v1/tables/eddytor/cfg_xxx/<uuid>_orders/columns/status/allowed-values
Authorization: Bearer edd_live_…get_allowed_values(table, "status")
# -> [{ "id": "…", "value": "active" }, { "id": "…", "value": "inactive" }, …]Each entry has an id (UUID) and a value. For a hierarchical column,
scope to one parent value to see the children allowed under it:
get_allowed_values(table, "subcategory", parent_value="Electronics")Good to know
Fixed domain values
# add one value
eddytor create domain-value eddytor sales orders status archived
# replace the whole list
eddytor set domain-values eddytor sales orders status --values active,inactive,archived
# remove one value
eddytor delete domain-value eddytor sales orders status draftPOST /v1/tables/…/columns/status/domain/values { "value": "archived" }
PUT /v1/tables/…/columns/status/domain/values { "values": ["active", "inactive", "archived"] }
DELETE /v1/tables/…/columns/status/domain/values/{value-id}Before removing a value, check nothing still uses it: eddytor get domain-usage … --field status --value draft (backed by the enum-in-use check). Removing a value
that rows still hold doesn't rewrite the rows - it orphans them;
validation finds the leftovers.
Hierarchy parents & children
Parents in an inline domain are keyed by the parent column's value ids; the children under each parent are values of this column.
# add a parent entry (value must exist in the parent column's domain)
eddytor create domain-parent eddytor sales orders subcategory "Home & Kitchen"
# add / replace / remove children under a parent
eddytor create domain-child eddytor sales orders subcategory "Home & Kitchen" "Cookware"
eddytor set domain-children eddytor sales orders subcategory "Home & Kitchen" --children Cookware,Furniture
eddytor delete domain-child eddytor sales orders subcategory "Home & Kitchen" "Cookware"
# remove a parent (and its children) from the mapping
eddytor delete domain-parent eddytor sales orders subcategory "Home & Kitchen"POST /v1/tables/…/columns/subcategory/domain/parents
{ "parent_id": "a1b2c3d4-…" } # parent column's value id
POST /v1/tables/…/columns/subcategory/domain/parents/{parent-id}/children
{ "child": "Cookware" }
PUT /v1/tables/…/columns/subcategory/domain/parents/{parent-id}/children
{ "children": ["Cookware", "Furniture"] } # replaces all children
DELETE /v1/tables/…/columns/subcategory/domain/parents/{parent-id}/children/{child-id}
DELETE /v1/tables/…/columns/subcategory/domain/parents/{parent-id}Heads up
set children replaces the parent's entire child list -
include every child you want to keep, not just new ones. A new parent entry
starts with an empty child list; rows can't use the parent/child pair until a
child is added.These endpoints apply to inline hierarchical domains only - derived and
table-lookup hierarchies have no stored mapping to edit (change the data or the
lookup table instead), and MCP callers re-send the full mapping via
set_column_domain.