Skip to main content
When to use this. Groups are optional admin-defined labels that organise styles (e.g. Woven, Knitwear, Denim) and compliance certificates (e.g. Sustainability, Chain of Custody) by fabric type, product purpose, or compliance focus. You create them once in Admin and users then select from them in the style header and the compliance module. Use these endpoints to build and maintain that library programmatically — for example when syncing with an ERP or migrating a client’s existing group taxonomy.

​
The workflow

Groups are organisation-scoped reference data. The typical path is to create your group taxonomy, then reference groups from styles or certificates through the respective style/compliance endpoints.
1

Create groups

POST /api/groups with an array of one or more groups — name is required, userDefinedId is optional but strongly recommended for ERP alignment. All items are created in a single all-or-nothing transaction.
2

Find groups

GET /api/groups with filters (State, Names, UserDefinedId, or free-text Search) to look up group IDs before referencing them on styles or in bulk operations.
3

Update or deactivate

PUT /api/groups/{id} to rename or change state to inactive so the group no longer appears in new-style dropdowns. Use the bulk PUT /api/groups to update many groups at once — including soft-deleting individual items within the same call.
4

Delete when unused

DELETE /api/groups/{id} soft-deletes a group. The call returns 400 if the group is still assigned to one or more styles (usedInStyles > 0); reassign those styles first.

​
Walkthrough

Create two groups in a single request. The body is an array — Knitwear and Denim are created together in one all-or-nothing transaction.
The response wraps the created groups in the standard envelope. Hold onto each id — styles and compliance certificates reference groups by it.

​
Field reference

The bulk PUT /api/groups endpoint accepts an array of GroupBulkUpdateDto objects. Setting state: "deleted" on an item within the array triggers the same delete-time rules as DELETE /api/groups/{id} — the group must have usedInStyles = 0.

​
Roles & permissions

Managing groups requires the company permission on a designer (brand) account — typically CompanyAdmin. Regular CompanyUser accounts and all supplier accounts cannot create or modify groups. For compliance groups specifically, CompanyAdmin combined with the Compliance Admin role is required in the Delogue UI; the API enforces the same operation-based permission check.

​
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. Common cases to handle:
  • 400 validation_error.* — name missing, or state: deleted sent to PUT /api/groups/{id} (use DELETE instead).
  • 400 on DELETE /api/groups/{id} — the group is still assigned to one or more styles (usedInStyles > 0). Reassign those styles to a different group first.
  • 404 resource_error.group_not_found — the id does not exist in your organisation.
  • 409 resource_conflict_error.* — name or userDefinedId already exists in the organisation.

​
What to call next

Style categories

Organise styles by product type (e.g. T-shirts, Dresses) — complements groups.

Seasons

The top-level structure every style is filed under; create seasons before styles.

Size ranges

Define the size sets that styles and items reference.

Styles

Create and manage styles that reference groups: POST /api/styles.