Skip to main content
When to use this. A style is the core product unit in Delogue PLM: it carries the design brief, BOM, files, sample requests, and supplier assignment for one product. Use these endpoints to create styles, manage their lifecycle (unpublished → published → delivered), update header fields and custom fields, and synchronise your collection with downstream systems.

The workflow

A style moves through a predictable lifecycle. The API mirrors that journey step by step.
1

Create the style

POST /api/styles with a brand, season, and style number. The style starts as unpublished — an internal draft not yet visible to the supplier.
2

Assign colours and fields

Update the style with PUT /api/styles/{styleId} to add colour variants (styleColors), custom field values (customFields), and a supplier assignment. Use PUT /api/styles (bulk) to update many styles in one request.
3

Publish to the supplier

Change state to published via PUT /api/styles/{styleId}. The supplier can now see the style. Note: once published a style cannot revert to unpublished.
4

Advance to delivered

When the style ships, set state to delivered. Delivered styles are archived and no longer appear in the default style list; retrieve them by filtering on state=delivered.

Walkthrough

Create a new style filed under a brand and season. The request body is an array — one or many styles are created in a single all-or-nothing transaction.
The response wraps the created styles in the standard envelope. Hold onto each id — it is the stable key for all subsequent style operations.

Field reference

The fields that matter most when creating or updating a style:
PUT /api/styles (bulk) and PUT /api/styles/{styleId} (single) both use patch semantics for nested collections: omitting styleColors, categories, or customFields preserves existing values. Provide [] to explicitly clear a collection.
Breaking change — GET /api/styles filter. The ReadyForExport query parameter is now a boolean (true/false) instead of an array of integers. Pass ReadyForExport=true to return only styles marked ready for export. Integrations that previously sent an integer list must switch to the boolean form.

Roles & permissions

Managing styles requires the styles permission on a designer (brand) account — typically CompanyAdmin or CompanyUser. Supplier accounts can read published styles assigned to them but cannot create or delete styles. Setting a style to workInProgress temporarily locks all supplier edits on that style (they can only view the header).

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:
  • 400 validation_error.required_fieldbrand or season was omitted on create.
  • 404 resource_error.style_not_found — the id in the path does not exist or belongs to another organisation.
  • 409 resource_conflict_error.style_already_exists — the customId is already in use within the organisation.
  • 422 unprocessable_error.* — a state transition was rejected (e.g. attempting to revert published to unpublished).

What to call next

Seasons

Every style requires a season. Create or look up seasons before creating styles.

Style categories

Tag styles with categories for filtering and collection reporting.

Style items

Add materials, trims, and fabrics to a style as style items.

Style custom fields

Extend style data with organisation-specific custom fields.

Sample requests

Request and track development samples against a style.

Style files

Attach and organise a style’s files and file folders.

Style SKUs

Read and manage a style’s colour/size SKU matrix.

Style prices

Look up a style’s negotiated and calculated prices.

Measurement charts

Read a style’s measurement chart, its lines, and files.

Supplier facilities

See which supplier facilities a style is produced at.