Turn enrichment on or off for an attribute
The one field worth changing on its own: it decides whether the next enrichment run may write this attribute, and therefore what a run costs.
apiKeyAuthorizationBearer <token>Your API key. X-Api-Key: <key> is accepted as an alternative.
A key belongs to an organization, not a user, so it outlives whoever created it. It carries two independent things, and both are checked: an org role (a member key cannot approve a publish or activate a mapping) and a set of scopes — catalog:read, catalog:write, enrichment:write, publishing:read, publishing:write, org:read, org:write. Holding a scope does not grant a role, and holding a role does not grant a scope.
GET /v1/me returns both for the key you are holding.
brandId*stringThe brand to read.
attributeId*stringapplication/json- body
extract*booleanThe flag as it now stands.
application/json- response
extract*booleanid*stringcurl -X PATCH 'https://fabric.inc/api/v1/brands/string/attributes/string/extract' \ -H 'Content-Type: application/json' \ -d '{ "extract": true}'{ "extract": true, "id": "string"}Update an attribute definition PUT
Replaces the editable fields. The `key` is not among them — every existing value joins on it, so re-keying would orphan the column. The FAQ, meta title and meta description attributes Fabric generates into (`fabric.faq`, `fabric.meta_title`, `fabric.meta_description`) keep their `kind` and `type`: changing either answers 409. Their name and `extract` stay editable, and `extract: false` stops Fabric generating them.
Move an attribute between product and variant scope PATCH
Scope says where an attribute's values live on a product that has variants; on a product without variants the attribute is the product's own either way. Moving to `variant` copies each product's value onto its variants that hold none (a variant's own value is never overwritten), then removes the product's value; a product without variants keeps its value as its own. Content Fabric writes per product cannot move to `variant`. Moving to `product` takes the value a product's variants agree on onto the product and removes it from the variants. Agreement is strict: every variant holds the same value, or none does. If any product disagrees, nothing moves and the answer is 409 with one `errors` entry per product (at most 20). Every value written is recorded in its history against the API key, and the change appears in the brand's activity. A move rewrites up to 25,000 variants in one transaction, so it sits on the `job` budget.