> ## Documentation Index
> Fetch the complete documentation index at: https://integration.delogue.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Manage groups
> Create and maintain the groups that classify styles by fabric type, product purpose, or compliance focus — optional but highly recommended for searchability and workflow clarity.
**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.
`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.
`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.
`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.
`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.
```mermaid theme={"dark"}
sequenceDiagram
participant D as Designer (admin)
participant API as Delogue API
D->>API: POST /api/groups (name, userDefinedId)
API-->>D: group ids
D->>API: GET /api/groups?State=active
API-->>D: paginated group list
D->>API: PUT /api/groups/{id} (state: inactive)
API-->>D: updated group
D->>API: DELETE /api/groups/{id}
API-->>D: state: deleted
```
## 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.
```bash cURL theme={"dark"}
curl -X POST "https://service.my.delogue.com/api/groups" \
-H "Accept: application/json" \
-H "X-Auth-Token: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '[
{
"name": "Knitwear",
"userDefinedId": "KNT-01",
"state": "active"
},
{
"name": "Denim",
"userDefinedId": "DNM-01",
"state": "active"
}
]'
```
```js JavaScript theme={"dark"}
const res = await fetch("https://service.my.delogue.com/api/groups", {
method: "POST",
headers: {
"Accept": "application/json",
"X-Auth-Token": "Bearer YOUR_API_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify([
{
"name": "Knitwear",
"userDefinedId": "KNT-01",
"state": "active"
},
{
"name": "Denim",
"userDefinedId": "DNM-01",
"state": "active"
}
]),
});
const { data } = await res.json();
```
```json theme={"dark"}
{
"status": "success",
"code": "groups_created",
"data": [
{
"id": 43601,
"name": "Knitwear",
"userDefinedId": "KNT-01",
"state": "active",
"properties": [],
"usedInStyles": 0,
"beginDate": "2026-06-30T12:00:00Z",
"endDate": "9999-12-31T23:59:59Z"
},
{
"id": 43602,
"name": "Denim",
"userDefinedId": "DNM-01",
"state": "active",
"properties": [],
"usedInStyles": 0,
"beginDate": "2026-06-30T12:00:00Z",
"endDate": "9999-12-31T23:59:59Z"
}
]
}
```
The response wraps the created groups in the standard envelope. Hold onto each
`id` — styles and compliance certificates reference groups by it.
## Field reference
| Field | What it means at Delogue |
| --------------- | ----------------------------------------------------------------------------------------------------------------------- |
| `name` | Display name of the group. Required. Must be unique within the organisation. |
| `state` | Initial lifecycle state of the group. Defaults to active if omitted. |
| `userDefinedId` | Optional customer-defined identifier for ERP/integration alignment. Must be unique within the organisation if provided. |
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](/concepts/errors) 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
Organise styles by product type (e.g. T-shirts, Dresses) — complements groups.
The top-level structure every style is filed under; create seasons before styles.
Define the size sets that styles and items reference.
Create and manage styles that reference groups: `POST /api/styles`.