Skip to main content
When to use this. Brands are the primary way to separate product data, certificates, and workflows for different labels within one organisation. At least one brand must exist before you can create styles or items. Use these endpoints to create brands, update their details, change their lifecycle state, and delete brands that are no longer needed.

​
The workflow

A brand is a designer-organisation-level record. The usual path is to create the brand, then create seasons and styles that reference it. Brands can be deactivated when a label is retired (styles on existing records are preserved) or deleted when they have never been used.
1

Create the brand

POST /api/brands with the brand name and optional address, country, and user-defined ID. New brands default to the Active state.
2

Create styles or items in it

POST /api/styles and POST /api/items both require a brand: a style or item cannot be created without one. The brand ID from the create response is the value to pass.
3

Find brands

GET /api/brands with filters (name, state, city, country, user-defined ID) to look brands up later or validate an integration’s data, or GET /api/brands/{id} to read one brand by its id.
4

Update, retire or delete the brand

PATCH /api/brands/{id} changes only the fields you send; PUT /api/brands/{id} replaces the brand in full, and PUT /api/brands replaces many brands in one all-or-nothing request. Set state to inactive to deactivate: inactive brands can no longer be selected on new styles or items but remain visible on existing ones. DELETE /api/brands/{id} for brands that were never attached to any style or item.

​
Walkthrough

Create a new brand for a label based in Copenhagen. The brand starts in the Active state by default.
The response wraps the created brand in the standard envelope. Hold onto the id: styles and items reference brands by it.

​
Field reference

PUT /api/brands/{id} and the bulk PUT /api/brands are full replaces: name and state are required on every call, and address, zipCode, city, stateOrProvince, countryId and userDefinedId are cleared when you send them as null or leave them out. Each bulk item also carries the id of the brand it replaces; an id that is not a brand in your organisation returns 404 against its [n].id. Neither PUT nor PATCH can set state to deleted: use DELETE /api/brands/{id}.
Prefer a partial update? PATCH /api/brands/{id} accepts an RFC 6902 JSON Patch document (Content-Type: application/json-patch+json) and touches only the paths you send; omitted fields keep their current values, and a replace with null on a nullable field (for example /address or /countryId) clears it.
POST /api/brands does not accept a logo. PUT and PATCH take an optional logo: a reference to an uploaded file resource to use as the brand logo. Because PUT is a full replace, omitting logo or sending it as null leaves the brand without a logo, so send the current logo back on every PUT if you want to keep it. On PATCH, the logo stays unless you replace /logo (with null to remove it).

​
Roles & permissions

Brands are managed from a designer (brand) account. Creating a brand requires the CompanyAdmin role; updating and deleting are available to designer users in the organisation that owns the brand. Supplier accounts can read the brands they collaborate with (including through GET /api/brands/{id}) but cannot create, update, or delete them.
At least one active brand must exist in your organisation before styles or items can be created. Creating the first brand is therefore usually the first admin step when onboarding a new organisation.

​
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 specific to brands:
  • 404 resource_error.brand_not_found: The brand ID does not exist.
  • 403 authorization_error.brand_access_denied: The brand belongs to a different organisation, or your account is not allowed to perform the operation.
  • 400 business_rule_error: Attempting to delete a brand that is assigned to one or more styles or items. Set it to inactive instead.
  • 400 validation_error: name was missing from a create or update request, state was missing from an update, or state: "deleted" was sent to PUT or PATCH.
  • 409 resource_conflict_error: a PATCH operation tried to change /id, or a test operation did not match the brand’s current values.
  • 422: a PATCH operation could not be applied (for example, a path that is not on the brand).

​
What to call next

Seasons

Create the seasons your styles will be filed under: a style requires both a brand and a season.

Style categories

Define style categories to organise your styles within a brand.

Size ranges

Set up size ranges that styles and items use within the brand.

Colours

Build the reusable colour library that styles and items reference as colourways.