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.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.Roles & permissions
Managing styles requires thestyles 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_field—brandorseasonwas omitted on create. - 404
resource_error.style_not_found— theidin the path does not exist or belongs to another organisation. - 409
resource_conflict_error.style_already_exists— thecustomIdis already in use within the organisation. - 422
unprocessable_error.*— a state transition was rejected (e.g. attempting to revertpublishedtounpublished).
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.