Update the server name and description

PATCH /v1/infra/servers/:id

Changes the server's display name and its description — two text fields visible in your Vibecode account and on the application card in the Bitrix24 catalog. The technical server identifier is set at creation and is not changed by this endpoint.

Parameters

Request fields (body)

The body accepts no other fields — for example, sending the technical identifier name in the body returns 400.

Examples

curl — personal key

curl -X PATCH https://vibecode.bitrix24.com/v1/infra/servers/6b23309f-7d0b-4cc3-a8f0-24183d48770e \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "Deal assistant",
    "description": "A bot for CRM. Answers questions about deals."
  }'

curl — OAuth application

curl -X PATCH https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "displayName": "Deal assistant",
    "description": "A bot for CRM. Answers questions about deals."
  }'

JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}`,
  {
    method: 'PATCH',
    headers: {
      'X-Api-Key': 'YOUR_API_KEY',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      displayName: 'Deal assistant',
      description: 'A bot for CRM. Answers questions about deals.',
    }),
  }
)
const { data } = await res.json()
console.log(data.displayName, data.description)

JavaScript — OAuth application

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}`,
  {
    method: 'PATCH',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      displayName: 'Deal assistant',
      description: 'A bot for CRM. Answers questions about deals.',
    }),
  }
)

Response fields

Response example

{
  "success": true,
  "data": {
    "id": "6b23309f-7d0b-4cc3-a8f0-24183d48770e",
    "name": "my-crm-app",
    "displayName": "Deal assistant",
    "description": "A bot for CRM. Answers questions about deals."
  }
}

A call without the description field — the previous description is kept, the key is absent from the response:

{
  "success": true,
  "data": {
    "id": "6b23309f-7d0b-4cc3-a8f0-24183d48770e",
    "name": "my-crm-app",
    "displayName": "Deal assistant"
  }
}

Error response example

404 — a server with this ID does not exist or belongs to another API key while you are not on its development team:

{
  "success": false,
  "error": {
    "code": "SERVER_NOT_FOUND",
    "message": "Server not found"
  }
}

Errors

The full list of common API errors — Errors.

Known specifics

• The update propagates to the application card in the Bitrix24 catalog. The display name is sent as the card title, the description as its description. A background process performs the synchronization, so the value appears in the catalog some time after the response. The card is updated only for an application that is already published in the catalog.
• The application in your account shows the same two values. When the server is linked to an application, the account takes the name and the description from the server, so the update is visible there as soon as the response arrives. The reverse holds too: a name changed on the application in your account changes the server's displayName — it is one value with two ways to edit it, and the last edit wins.
• A call that changed nothing has no effect. If the sent values match the current ones, the platform writes nothing to the database, records no audit log entry, and schedules no catalog synchronization. The response is the usual 200 — it cannot tell you whether the record changed.
• Non-ASCII characters in displayName and description from Windows PowerShell. Sent without explicit UTF-8 serialization, they are stored as question marks (?): the bytes are lost on the client side, before the request is sent. A ready-to-run call with UTF8.GetBytes — Windows / PowerShell and UTF-8. The platform accepts such a value and stores it as is, but it reports the loss: the response carries warnings listing the affected fields. The warning is emitted only for a field this call actually changed — re-sending the same value stays silent.
• An application key is not accepted here. GET /v1/infra/servers/:id also returns the server for the personal key of the application the server is bound to. The update does not work that way: it requires exactly the key that manages the server, otherwise the response is 404. How to change the managing key — Server access recovery.

See also

• Create a server
• Get a server
• List servers
• Delete a server
• App icon