Brands

Catalog brands (marcas).

📄️ Get brand by ID

Returns a single brand by its primary key. The response carries a strong `ETag` header with the current version.

📄️ Update brand

Full replacement of an existing brand. Send the `If-Match` header with the current ETag for optimistic concurrency control.

📄️ Delete brand

Deletes a brand. Send the `If-Match` header with the current ETag for optimistic concurrency control.

📄️ Merge-patch brand

RFC 7396 merge-patch over `application/merge-patch+json`. Send only the fields you want to change; include a field with value `null` to remove it. Use the `If-Match` header for optimistic concurrency control.

📄️ List brands

Returns a paginated list of brands with envelope `{data, totalCount, skip, limit, hasMore}`. Supports optional RSQL `filter`, `sort` (default `name:asc`), `skip`/`limit` pagination and `modifiedAfter`/`modifiedBefore` bookends. Limit is capped at 200; skip is clamped to >= 0.

📄️ Create brand

Creates a new brand. Business logic runs in the legacy WAR via the internal commands gateway.

📄️ Bulk delete brands

Removes every id in `ids` as a single all-or-nothing transaction. If any id is missing or outside the user's company scope the whole operation is rolled back. There is no `If-Match` header on this endpoint because a single ETag cannot represent a heterogeneous selection. The request body is mandatory; clients that cannot send a body on `DELETE` should fall back to the per-id endpoint `DELETE /api/v2/brands/{id}`.

📄️ Bulk patch brands

Applies the same `patch` to every id in `ids` as a single all-or-nothing transaction. Editable fields are restricted to a whitelist (`enabled`, `blockType`, `description`, `groupId`, `campaignId`); identity (`code`, `name`), multi-tenant scope (`companyId`) and audit fields are rejected. If any id is missing or outside the user's company scope the whole operation is rolled back. There is no `If-Match` header on this endpoint.

📄️ Prototype brand for a creation form

Returns a non-persisted brand pre-populated with the authenticated user's defaults (current company, `enabled=true`, `blockType=null`). The response carries no `id`, `version` or audit fields. The optional JSON body supplies initialisation hints understood by the WAR; currently recognised: `companyId`, `groupId`, `campaignId` and `copyFromId` (replicates code/name/description from an existing brand). Caller must follow up with `POST /api/v2/brands` to actually persist the entity.