When to use this. Colours are reusable library entities for a brand: you create them
once, optionally organise them into colour groups, and then reference them as colourways on
items and styles. Use these endpoints to build and maintain that library.
The workflow
A colour is a brand-level record in the colour library. The usual path is to (optionally) set up colour groups for organisation, create the colours, then reference them from items and styles further along the product lifecycle.1
Group (optional)
POST /api/color-groups to create groups (e.g. “Blues”, “Core”) you’ll file colours under.2
Create colours
POST /api/colors with the colour details, attaching colorGroupIds to file them.3
Find colours
GET /api/colors with filters (name, reference, state, group) to look colours up later.4
Reference on products
Colours surface as colourways on items and style-items — see
GET /api/items/{itemId}/colors and GET /api/styles/{styleId}/items/{styleItemId}/colors.Walkthrough
Create a colour and file it under a colour group. The body is an array — one or many colours are created in a single all-or-nothing transaction.id — items
and styles reference colours by it.
Field reference
The fields that matter most when creating or updating a colour:Roles & permissions
Managing the colour library requires thecolors permission on a designer (brand)
account — typically CompanyAdmin or CompanyUser. Supplier accounts collaborate on styles
but do not manage a brand’s colour library.
When things go wrong
Errors use the standard envelope (status: "error", a code, and error.details[]). See
Errors & responses for the full list of codes and how to resolve them.
What to call next
Colour groups
Organise colours into groups for filtering and reuse.
Item colours
See which colours are used on an item:
GET /api/items/{itemId}/colors.Style-item colours
Colours on a style’s items:
GET /api/styles/{styleId}/items/{styleItemId}/colors.Authentication
How to get and send your
X-Auth-Token API key.