Skip to main content
When to use this. Items are the reusable components of your styles: fabrics, zippers, buttons, labels, packaging, and more. You create them once in the item library (with a brand, supplier, sizes, quality details, and colour cards), then reference them across as many styles as needed. Use these endpoints to build and maintain that library.

The workflow

An item lives independently of any particular style, which lets you start sourcing before a design is finalised. The typical path is to create the item, enrich its specifications, and then add it to style item lists.
1

Create the item

POST /api/items with at minimum a name and a brand. Assign a supplier and contact persons, set the default quantity, and file it under one or more categories (e.g. Fabric, Zipper, Button).
2

Add sizes and colour cards

Sizes and colour cards are managed via the Delogue Classic / 2.0 UI today. Read them back with GET /api/items/{itemId}/sizes and GET /api/items/{itemId}/colors to verify or cross-reference.
3

Check quality details and prices

GET /api/items/{itemId}/parts returns the material composition (percentage + material) and per-colour specifications. GET /api/items/{itemId}/prices returns the agreed cost price with currency and lead time: useful for feeding cost calculations.
4

Update or search

PUT /api/items/{itemId} for a full replace, PATCH /api/items/{itemId} for targeted field changes (RFC 6902 JSON Patch). GET /api/items with filters (name, category, supplier, brand, custom fields, active flag) to page through the library, or GET /api/items/{itemId} to read one item with its brand, supplier, categories, custom fields, unit and logo.

Walkthrough

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

Field reference

The fields that matter most when creating or updating an item:
PUT /api/items/{itemId} is a full replace: send all fields you want to keep. Use PATCH /api/items/{itemId} (RFC 6902 JSON Patch) for targeted changes such as updating a single field, e.g. [{ "op": "replace", "path": "/description", "value": "new value" }]. Bulk update is available via PUT /api/items (array body).
Breaking change: item customFields request shape. Each entry in a customFields array now uses:
  • id (required): the custom-field definition id. This replaces the former customFieldId. Note the repurposing: on the old update shape id was the existing custom-field value row id (nullable, null to add a new value); that row identifier is gone, and id now always means the definition id. An update that keeps sending the old row id in id will silently target the wrong custom field with no error: send the definition id.
  • value: a single value for text, date, numeric, or single-select fields. For an allowed-value field, set value.id to the allowed-value id (this replaces the former itemCustomFieldAllowedValueId).
  • values: an array of values for multi-select allowed-value fields; a given field id must appear only once, so send multiple selections here rather than repeating the entry.
The removed properties customFieldId, itemCustomFieldAllowedValueId, and customFieldAllowedValueUserDefinedID are no longer accepted on the request; the allowed-value user-defined id is now resolved server-side. Existing integrations must migrate to the id / value / values shape.

Roles & permissions

Managing the item library requires the items permission on a designer (brand) account, typically CompanyAdmin or CompanyUser. Creating and deleting items is designer-only: supplier users receive 403. On an update, a supplier user may change only description (and custom fields marked supplier-editable); touching any other field returns 403. DELETE /api/items/{itemId} returns 409 Conflict if the item is still used in a style.

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 for items:
  • 400: a required field (e.g. name, brand.id) is missing or too long, a brand, supplier, contact-person or category id is not found, or readyForExport: true was sent while one or more mandatory custom fields are empty (business_rule_error).
  • 403: the itemId belongs to another organisation, or your account is not allowed to make the change.
  • 404: the itemId does not exist.
  • 409: the item’s identifiers clash with an existing item, or you are deleting an item that is still used in a style.
  • 422: a PATCH operation cannot be applied to the item.

What to call next

Item categories

Set up the category taxonomy (Fabric, Zipper, Button…) before creating items.

Colours

Build the colour library that item colour cards reference.

Size ranges

Manage the size sets available to items and styles.

Style items

Add items from the library to a style’s item list.