For AI agents: markdown of this page — /docs-content-en/entities/catalog-services/update.md documentation index — /llms.txt

Update a service

PATCH /v1/catalog-services/:id

Updates an existing catalog service. Fields are passed flat at the root of the JSON; pass only the fields you change — the rest keep their current values.

Parameters

Parameter Type Required Description
id (path) number yes Service identifier. List: GET /v1/catalog-services

Request fields (body)

The main writable fields are name, active, available, and iblockSectionId.

Field Type Required Description
name string no Service name
active boolean no Whether the service is active
available boolean no Whether the service is available for purchase
iblockSectionId number no Main catalog section ID. List: GET /v1/catalog-sections
iblockSection array no Array of IDs of all catalog sections the service belongs to. List: GET /v1/catalog-sections
measure number no Unit of measure ID. List: GET /v1/catalog-measures
vatIncluded boolean no Whether VAT is included in the price
vatId number no VAT rate ID. List: GET /v1/catalog-vat-rates
code string no Symbolic code
xmlId string no External code
sort number no Sort order
previewText string no Preview text
previewTextType string no Preview text format: text or html
detailText string no Detailed description
detailTextType string no Detailed description format: text or html
previewPicture object no Preview picture
detailPicture object no Detail picture
propertyNNN object no Catalog property value, where NNN is the property id from GET /v1/catalog-product-properties. Passed as an object: "property301": { "value": "A-300" }

The body must contain at least one writable field. An empty PATCH is rejected with 400 EMPTY_UPDATE_BODY, and a body with only unknown field names is rejected with 400 NO_RECOGNIZED_UPDATE_FIELDS.

The iblockId field is not accepted on update: the catalog is set on creation. Fields marked readonly: true in Service fields, for example type and createdBy, are filled in by the system. Any of these fields in the body is rejected with 400 READONLY_FIELD.

Examples

curl — personal key

Terminal
curl -X PATCH "https://vibecode.bitrix24.com/v1/catalog-services/7231" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Turnkey air conditioner installation"
  }'

curl — OAuth application

Terminal
curl -X PATCH "https://vibecode.bitrix24.com/v1/catalog-services/7231" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Turnkey air conditioner installation"
  }'

JavaScript — personal key

javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/catalog-services/7231', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Turnkey air conditioner installation',
  }),
})

const { success, data } = await res.json()
console.log('Name:', data.name)

JavaScript — OAuth application

javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/catalog-services/7231', {
  method: 'PATCH',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    name: 'Turnkey air conditioner installation',
  }),
})

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

Response fields

Field Type Description
success boolean Always true on success
data object Full object of the updated service. The field set is the same as in GET /v1/catalog-services/:id

Response example

The main fields are shown.

JSON
{
  "success": true,
  "data": {
    "id": 7231,
    "iblockId": 25,
    "iblockSectionId": 281,
    "iblockSection": [281],
    "name": "Turnkey air conditioner installation",
    "type": 7,
    "active": true,
    "available": false,
    "xmlId": "7231",
    "sort": 500,
    "measure": 9,
    "vatIncluded": true,
    "dateCreate": "2026-10-08T20:50:59.000Z",
    "timestampX": "2026-10-08T20:52:26.000Z"
  }
}

Error response example

404 — no service with the specified id exists:

JSON
{
  "success": false,
  "error": {
    "code": "ENTITY_NOT_FOUND",
    "message": "service does not exist."
  }
}

Errors

HTTP Code Description
404 ENTITY_NOT_FOUND No record with the specified id exists, or the record is not a service — for example, a regular catalog product (service does not exist.). The record is not changed
400 EMPTY_UPDATE_BODY The request body is empty — pass at least one field
400 NO_RECOGNIZED_UPDATE_FIELDS The body contains no recognized writable field. The message lists the allowed ones
400 READONLY_FIELD The body contains a field that is not accepted on update: iblockId or a read-only field, for example type
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

A catalog property changes only when passed as an object. A PATCH with a string — "property301": "A-200" — or with null returns 200, but the property value does not change. Pass the new value as an object { "value": "..." }. When you create a service, a string property also accepts a plain string.

iblockSectionId replaces all of the service's sections. If the service belongs to several sections, a PATCH with iblockSectionId leaves it only in the specified section — the iblockSection array in the response contains one ID. To keep several sections, pass them as a full array in iblockSection.

Unknown field names next to known ones are ignored. A body with name and a field name that the service does not have returns 200: name is written, and the unknown name is dropped without a warning.

See also