Channels controls which of your seasons are exposed to the integration API, so connected systems such as a webshop or ERP receive only the seasons meant for them. Each channel has a name and a key, and seasons are assigned to channels.
Creating a channel
Click Add channel, enter a name and a key, and create it. The key is the stable identifier that integrations reference, so it's worth leaving unchanged once external systems rely on it. A channel can be marked strict that exposes only current or past seasons through the API; future seasons are withheld until they become current. A channel that isn't strict serves upcoming seasons as well.
Channels and seasons
Seasons are assigned to channels on the Seasons page, where a season can be active for one channel and not another. That assignment determines which seasons a given integration receives. If a channel has no active seasons, the system flags it so the gap is visible.
Channels, technically
A channel is a distinct sales or distribution context — Retail, Wholesale, E-commerce, and so on. Every brand has at least one channel; a default one is created when the brand is set up, and the last remaining channel can't be deleted. Each channel has a name and a key (both unique within the brand). The key is generated from the name and is the stable identifier integrations rely on — in the v3 API it's used as the dictionary key for that channel's data. The order of channels matters: the first channel is the brand's main channel and has special significance (it drives the v2 API and season ordering, below).
Channel activities and dates
A season is attached to a channel by a channel activity — a date range with a start and an end (both inclusive). A season can have at most one activity per channel, and an activity is active when today falls within its range. You manage activities on the Seasons page, in either the table or Gantt view — see Seasons and drops.
Two activities on the same channel can't overlap. When you set an activity that would overlap existing ones, the system adjusts the neighbours automatically:
If the new range fully contains an existing activity, that activity is removed.
If the new range overlaps the start of an existing activity, that activity's start moves to the day after your new end.
If the new range overlaps the end of an existing activity — or sits inside it — that activity's end moves to the day before your new start (ranges are never split).
The Seasons page lists exactly which seasons will be affected before you save.
How seasons are ordered
Seasons are ordered by the first channel's end date, latest first. Seasons with no activity on the first channel sort last. This ordering is recomputed whenever a channel activity is added, changed or removed, or when channels are reordered.
Channels in the integration API
The two API versions treat channels differently:
v2 (legacy) — always uses the first channel to decide which season is active. The consumer has no visibility into channels.
v3 (current) — returns data per channel, as a dictionary keyed by the channel key.
A single-article v3 response is keyed by channel:
{
"retail": { "articleNumber": "ART-001", "currentSeason": "AW24", "isCurrentChannelSeason": true, ... },
"wholesale": { "articleNumber": "ART-001", "currentSeason": "SS24", "isCurrentChannelSeason": false, ... }
}
The batch endpoints (GET v3/articles, POST v3/articles/by-numbers) wrap each article with its number and a channels dictionary, alongside the pagination envelope:
{
"items": [
{ "articleNumber": "ART-001", "channels": { "retail": { ... }, "wholesale": { ... } } }
],
"pagination": { "count": 1, "totalCount": 50, "hasMore": true, "offset": 0, "limit": 50 }
}
Each channel entry reports a currentSeason (the season whose data is returned for that channel) and isCurrentChannelSeason (whether that season is active today, below).
Which season each channel returns
For a given article, each channel resolves to one season's data, and the strict setting decides how far the search reaches:
Strict (the default) — only the channel's current or past mapped seasons are considered: the active season first, then past seasons most-recent-first. If the article has no current or past mapped season on that channel, the channel returns null for it.
Non-strict — the same, plus upcoming mapped seasons (soonest first). If none of the article's seasons are mapped to the channel at all, it falls back through the brand's remaining seasons by proximity, and finally to the article's seasonless base data — so a non-strict channel never returns null.
isCurrentChannelSeason is true only when the season returned has an activity that is active today; it's false when a past (or fallback) season's data is returned. When only seasonless base data applies, currentSeason is the sentinel value null-season.
For example, with a non-strict Retail channel and a strict Wholesale channel: for an article whose seasons include the current one, both channels return their active season. For an article that only has upcoming seasons, the non-strict Retail channel returns its earliest upcoming season, while the strict Wholesale channel returns null — because the article has no current or past season there.
Channels in webhooks
When a webhook embeds the resource (the Include resource option), its shape matches the API version the webhook is set to: a v2 webhook carries the flat first-channel article, while a v3 webhook carries the same channel-keyed dictionary as the v3 endpoint. When an article is deleted the ping is still sent so consumers learn of the deletion, but only the path is included — the resource is omitted.