Manage seasons

When to use this. A season is the top-level parameter every style is organised by, and a brand can have as many as it needs. A style cannot be created without one, so seasons are usually the first admin data you set up. Use these endpoints to create seasons, group them by project, and retire them once a collection closes.

The workflow

Seasons sit at the top of the product structure: you create a season, file styles under it, and later deactivate or lock it when the collection is done. Many brands also use the project field to sub-divide a season into drops or collaboration collections.

Create the season

POST /api/seasons with the season name (and optionally a project and custom ID). Only designer users can create seasons.

Look seasons up

GET /api/seasons returns a paginated list, filtered by Search, Names, Project, CustomId or State; add Properties=isLocked to return only locked seasons. Fetch a single season with GET /api/seasons/{id}.

Create styles in it

POST /api/styles references the season: a style cannot be created without one.

Find styles by season

GET /api/styles with season.id (or season.name / season.project) to pull everything in a season later.

Retire the season

PUT /api/seasons/{id} to set state to inactive so it is no longer offered for new styles (or PUT /api/seasons to retire several seasons in one call), or DELETE /api/seasons/{id} to soft-delete it.

Walkthrough

Create a season for next spring/summer. The body is an array: one or many seasons are created in a single all-or-nothing transaction.

curl -X POST "https://service.my.delogue.com/api/seasons" \
  -H "Accept: application/json" \
  -H "X-Auth-Token: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
  {
    "name": "SS29",
    "project": "Main collection",
    "customId": "SS29",
    "state": "active"
  }
]'

const res = await fetch("https://service.my.delogue.com/api/seasons", {
  method: "POST",
  headers: {
    "Accept": "application/json",
    "X-Auth-Token": "Bearer YOUR_API_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify([
  {
    "name": "SS29",
    "project": "Main collection",
    "customId": "SS29",
    "state": "active"
  }
]),
});
const { data } = await res.json();

{
  "status": "success",
  "code": "seasons_created",
  "data": [
    {
      "id": 4821,
      "name": "SS29",
      "project": "Main collection",
      "customId": "SS29",
      "state": "active",
      "properties": []
    }
  ]
}

The response wraps the created seasons in the standard envelope. Hold onto each id: styles reference seasons by it.

Field reference

The fields that matter most when creating or updating a season:

Field	What it means at Delogue
`id`	The season to update. Bulk `PUT /api/seasons` only: required on every item; the single-season endpoints take the id from the route.
`customId`	Customer-defined season identifier, useful for ERP alignment. Optional, up to 100 characters.
`name`	Display name of the season, e.g. SS29. Required, up to 200 characters.
`project`	Project within the season for seasonal drops or collaboration collections. Optional, up to 100 characters.
`state`	Lifecycle state, active or inactive. Defaults to active when omitted on create; required on `PUT`, where the value deleted is rejected: use `DELETE /api/seasons/{id}` instead.

PUT is a full replace and requires name and state on every item: include the current value of any field you don’t intend to change. Fields that are not on the public contract (price-confirmation deadline, milestones, position and access) keep their stored values. To update several seasons at once, send an array to PUT /api/seasons with each season’s id; the batch is updated in a single all-or-nothing transaction.

Prefer a partial update? PATCH /api/seasons/{id} accepts an RFC 6902 JSON Patch document (Content-Type: application/json-patch+json) and touches only the paths you send: /name, /project, /customId, and /state. state still cannot be set to deleted (use DELETE /api/seasons/{id}), and name cannot be cleared.

Roles & permissions

Managing seasons requires a designer (brand) account. Creating a season requires the CompanyAdmin role; any designer user in the organisation can update or delete its seasons. Supplier accounts collaborate on styles but do not manage a brand’s seasons. A locked season cannot be updated or deleted: those calls return 403, and a bulk PUT that includes one is rejected as a whole. GET /api/seasons/{id}, PUT and PATCH return 403 for a season that belongs to another organisation and 404 for an id that does not exist.

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.

What to call next

Styles

Create styles in the season: POST /api/styles, then filter with GET /api/styles?season.id=.

Sample types

Season milestone deadlines are driven by sample types: GET /api/sample-types.

Groups

Another way to organise styles: GET /api/groups.

Authentication

How to get and send your X-Auth-Token API key.

Getting Started

Concepts

Guides

The workflow

Walkthrough

Field reference

Roles & permissions

When things go wrong

What to call next

Styles

Sample types

Groups

Authentication

​The workflow

​Walkthrough

​Field reference

​Roles & permissions

​When things go wrong

​What to call next

Styles

Sample types

Groups

Authentication

The workflow

Walkthrough

Field reference

Roles & permissions

When things go wrong

What to call next