Skip to main content
When to use this. Style categories are reusable library entities for a brand: you define them once in Admin and then assign one or more categories to each style. They are optional, but Delogue recommends mirroring your webshop category structure so downstream systems and integrations receive consistent classification data. A style can carry multiple categories; use these endpoints to build and maintain that library.

The workflow

Style categories sit alongside seasons and groups as the key classification dimensions for a brand’s style library. The usual path is to create the categories that reflect your product types, assign them to styles, and deactivate or delete them when they are no longer needed.
1

Create categories

POST /api/style-categories with the category name and optional user-defined ID. One or many categories are created in a single all-or-nothing transaction.
2

Find categories

GET /api/style-categories with filters (name, user-defined ID, state) to look categories up or verify that they exist before assigning them to styles. GET /api/style-categories/{id} fetches a single category by its id.
3

Assign to styles

Styles reference categories on creation and update: see your styles endpoints. A style can carry multiple categories, separated by the caller.
4

Retire a category

PUT /api/style-categories/{id} to set state to inactive so the category can no longer be assigned: a style create or update that references an inactive category is rejected with 400. Or DELETE /api/style-categories/{id} to delete it permanently; the call returns 409 while the category is in use by styles or referenced by style custom field differentiation rules.

Walkthrough

Create a style category. The body is an array: one or many categories are created in a single all-or-nothing transaction.
The response wraps the created categories in the standard envelope. Hold onto each id: styles reference categories by it.

Field reference

The fields that matter most when creating or updating a style category:
PUT /api/style-categories/{id} and the bulk PUT /api/style-categories are full replaces: every field is written as sent, name and state are required, and an omitted userDefinedId clears it: include the current value of any field you don’t intend to change. state: "deleted" is rejected with 400; use DELETE to remove a category. The bulk PUT takes an array of up to 200 items, each carrying the id of the category it replaces, and is all-or-nothing: duplicate ids in the batch are rejected, and one failing item rolls back the whole batch.
For a partial update, PATCH /api/style-categories/{id} accepts an RFC 6902 JSON Patch document (Content-Type: application/json-patch+json) and touches only the paths you send (/name, /userDefinedId, /state). To remove several categories at once, DELETE /api/style-categories?ids=1&ids=2 (repeated ids) permanently deletes them in one all-or-nothing call; each deleted category comes back with state: "inactive".

Roles & permissions

Managing style categories requires admin access on the styles permission on a designer (brand) account: typically CompanyAdmin. Regular designer users (CompanyUser) can read categories but cannot create or modify them. Supplier accounts cannot manage a brand’s style categories.

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. An id that exists in no organisation returns 404; a category that belongs to another organisation returns 403. On the bulk PUT, error.details[] points at each failing item by index, and a name or user-defined ID already used by another category returns 409.

What to call next

Seasons

Another top-level classification for styles: create seasons before assigning categories.

Colours

Build the brand’s colour library that styles and items reference as colourways.

Styles

Create and update styles that reference categories: POST /api/styles.

Authentication

How to get and send your X-Auth-Token API key.