One custom field definition
One custom field definition by its id: name, field_type, source, description, is_active, is_editable, is_value_editable, access_type and its timestamps.
The id is the one a variant's custom_fields map is keyed on, so this is the read that turns a key in that map into a name and a type.
is_value_editable is computed rather than stored: true when source is tightly, and otherwise true only when access_type is read_write. A field brought by a connector as read_only cannot take a value from here, whatever is_editable says about the definition.
A field id that does not exist in this organisation is refused 404. For every definition at once, read the list.
Scope: products:read.
Request
- Base URL: https://api.app.tightly.io
- URL: https://api.app.tightly.io/api/v1/variants/custom-fields/{custom_field_id}
- Auth: HTTP bearer
Path parameters
The definition this reads, as a variant's custom_fields map keys it.
Headers
The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.
Response
The definition.
Example response
{
"data": {
"custom_field": {
"access_type": "read_only",
"bound_to": {
"field_key": "product.custom_field.fabric",
"source_path": "metafields.custom.fabric"
},
"description": "The mill's stated composition.",
"field_type": "string",
"grain": "product",
"id": "123",
"is_active": true,
"is_editable": true,
"is_value_editable": true,
"label": "Fabric",
"name": "fabric",
"source": "tightly"
}
}
}Changes
No recorded changes to this operation across all 1 revision of this API.