> ## Documentation Index
> Fetch the complete documentation index at: https://integration.delogue.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Manage brands
> Create and maintain the brands that every style and item is organised under — the top-level label structure for your organisation in Delogue.
**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.
`POST /api/brands` with the brand name and optional address, country, and user-defined ID.
New brands default to the `Active` state.
`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.
`GET /api/brands` with filters (name, state, city, country, user-defined ID) to look brands
up later or validate an integration's data.
`PUT /api/brands/{id}` with `state: "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.
```mermaid theme={"dark"}
sequenceDiagram
participant D as Designer
participant API as Delogue API
D->>API: POST /api/brands
API-->>D: brand id (e.g. 42)
D->>API: POST /api/seasons
API-->>D: season id
D->>API: POST /api/styles (referencing brand + season)
API-->>D: style id
D->>API: PUT /api/brands/{id} (state: Inactive)
API-->>D: updated brand
```
## Walkthrough
Create a new brand for a label based in Copenhagen. The brand starts in the `Active` state by
default.
```bash cURL theme={"dark"}
curl -X POST "https://service.my.delogue.com/api/brands" \
-H "Accept: application/json" \
-H "X-Auth-Token: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Urban Essentials",
"address": "Vesterbrogade 42",
"zipCode": "1620",
"city": "Copenhagen",
"stateOrProvince": "",
"countryId": 59,
"state": "active",
"userDefinedId": "UE-01"
}'
```
```js JavaScript theme={"dark"}
const res = await fetch("https://service.my.delogue.com/api/brands", {
method: "POST",
headers: {
"Accept": "application/json",
"X-Auth-Token": "Bearer YOUR_API_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify({
"name": "Urban Essentials",
"address": "Vesterbrogade 42",
"zipCode": "1620",
"city": "Copenhagen",
"stateOrProvince": "",
"countryId": 59,
"state": "active",
"userDefinedId": "UE-01"
}),
});
const { data } = await res.json();
```
```json theme={"dark"}
{
"status": "success",
"code": "brand_created",
"data": {
"id": 42,
"name": "Urban Essentials",
"organizationId": 13,
"state": "active",
"properties": [],
"address": "Vesterbrogade 42",
"zipCode": "1620",
"city": "Copenhagen",
"stateOrProvince": "",
"country": {
"id": 59,
"name": "Denmark",
"code": "DK"
},
"logo": {
"id": "e1f4b7a2-3c9d-4e6f-8a1b-2d5e7f9c3a6d",
"url": "https://cdn.delogue.com/brands/42/logo.png"
},
"marginFactor": null,
"userDefinedId": "UE-01",
"logoThumbnails": []
}
}
```
The response wraps the created brand in the standard envelope. Hold onto the `id` — styles and
items reference brands by it.
## Field reference
| Field | What it means at Delogue |
| ----------------- | ------------------------------------------------------------------------------------------- |
| `address` | Street address of the brand office. |
| `city` | City of the brand office. |
| `countryId` | ID of the country associated with the brand office. Omit or pass null for no country. |
| `name` | Display name of the brand. Required. |
| `state` | Initial lifecycle state of the brand. Defaults to active. |
| `stateOrProvince` | State or province of the brand office. |
| `userDefinedId` | Customer-defined identifier for the brand. Used in data imports, exports, and integrations. |
| `zipCode` | Postal or ZIP code of the brand office. |
**Breaking change.** The `logo` property was removed from the `POST /api/brands` and
`PUT /api/brands/{id}` request bodies — these endpoints no longer accept a logo. Brand responses
still return `logo` and `logoThumbnails`, but a brand's logo is **read-only through this API** —
there is currently no endpoint to upload or change it.
## Roles & permissions
Managing brands requires the **`brands`** permission on a **designer (brand)** account —
typically `CompanyAdmin`. Supplier accounts collaborate on styles and items but do not manage
a brand's configuration.
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](/concepts/errors) 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 or belongs to a
different organisation.
* **409 conflict** — Attempting to delete a brand that is assigned to one or more styles or
items. Set it to `Inactive` instead.
* **400 `validation_error.required_field`** — `name` was missing from a create or update
request.
## What to call next
Create the seasons your styles will be filed under — a style requires both a brand and a
season.
Define style categories to organise your styles within a brand.
Set up size ranges that styles and items use within the brand.
Build the reusable colour library that styles and items reference as colourways.