Untuk agen AI: markdown halaman ini — /docs-content-en/entities/catalog-skus.md indeks dokumentasi — /llms.txt

Artikel dokumentasi saat ini tersedia dalam bahasa Inggris.

Catalog SKUs

An SKU, or parent product, is the shared card of a product with offers: it has one name, description, and catalog section, while sizes, colors, and other variants are stored in catalog offers. The methods in this section create, read, update, and delete parent products.

Bitrix24 API: catalog.product.sku.* Scope: catalog

Create an SKU

POST /v1/catalog-skus

Creates a parent product in the product catalog — a shared card to which offers are then linked. Fields are passed flat at the root of the JSON.

Request fields (body)

Field Type Required Description
name string yes Parent product name
iblockId number yes Product catalog ID. List: GET /v1/catalogs. An offer catalog — one with productIblockId filled in — is not accepted
active boolean no Whether the product is active. Defaults to true
iblockSectionId number no ID of the main catalog section. List: GET /v1/catalog-sections
iblockSection number[] no Array of IDs of all sections the product is linked to. List: GET /v1/catalog-sections
code string no Product symbolic code
xmlId string no External code. If omitted, Bitrix24 sets it to the product id as a string
sort number no Sort order. Defaults to 500
dateActiveFrom datetime no Activity start date
dateActiveTo datetime no Activity end date
previewText string no Preview text
previewTextType string no Preview text format: text or html. Defaults to text
detailText string no Detailed description
detailTextType string no Detailed description format: text or html. Defaults to text
previewPicture object no Preview picture: { "fileData": ["name.png", "<base64>"] }
detailPicture object no Detail picture, same format
propertyNNN string no Catalog property value, where NNN is the property id from GET /v1/catalog-product-properties: "property301": "cotton"

The type, available, and bundle fields are computed by Bitrix24 — in the request body they are rejected with 400 READONLY_FIELD.

Examples

curl — personal key

Terminal 
curl -X POST "https://vibecode.bitrix24.com/v1/catalog-skus" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Basic T-shirt",
    "iblockId": 25,
    "active": true
  }'

curl — OAuth application

Terminal 
curl -X POST "https://vibecode.bitrix24.com/v1/catalog-skus" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Basic T-shirt",
    "iblockId": 25,
    "active": true
  }'

JavaScript — personal key

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/catalog-skus', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Basic T-shirt',
    iblockId: 25,
    active: true,
  }),
})

const { success, data } = await res.json()
console.log('Parent product ID:', data.id)

JavaScript — OAuth application

javascript 
const res = await fetch('https://vibecode.bitrix24.com/v1/catalog-skus', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Basic T-shirt',
    iblockId: 25,
    active: true,
  }),
})

const { success, data } = await res.json()

Response fields

Field Type Description
success boolean Always true on success
data object Full object of the created parent product. The field set is the same as for GET /v1/catalog-skus/:id

Response example

The main fields are shown; propertyNNN properties are omitted. A newly created parent product has type equal to 6.

JSON 
{
  "success": true,
  "data": {
    "id": 7203,
    "iblockId": 25,
    "iblockSectionId": null,
    "iblockSection": null,
    "name": "Basic T-shirt",
    "type": 6,
    "active": true,
    "available": false,
    "bundle": false,
    "code": null,
    "xmlId": "7203",
    "sort": 500,
    "previewText": null,
    "previewTextType": "text",
    "detailText": null,
    "detailTextType": "text",
    "createdBy": 1295,
    "modifiedBy": 1295,
    "dateCreate": "2026-10-08T18:45:34.000Z",
    "timestampX": "2026-10-08T18:45:34.000Z"
  }
}

Error response example

400 — a required field was not passed:

JSON 
{
  "success": false,
  "error": {
    "code": "MISSING_REQUIRED_FIELDS",
    "message": "Body field \"name\" is required to create catalogSku."
  }
}

Errors

HTTP Code Description
400 MISSING_REQUIRED_FIELDS The required field name or iblockId was not passed — the message names it. The request is rejected before it reaches Bitrix24
400 READONLY_FIELD A read-only field was passed in the body: type, available, bundle
422 BITRIX_ERROR iblockId points to an offer catalog (productType is not allowed for this catalog)
422 BITRIX_ERROR iblockId is not a catalog (iblock is not catalog)
403 SCOPE_DENIED The key lacks the catalog scope
401 MISSING_API_KEY The X-Api-Key header was not passed

Full list of common API errors — Errors.

Known specifics

The type changes once an offer is linked. A new parent product has type: 6. When the first offer is linked to it — POST /v1/catalog-offers with parentId — the type becomes 3. There is no need to change the type separately, and it cannot be passed.

See also