Publish the app to the Bitrix24 catalog

POST /v1/infra/servers/:id/b24-catalog/publish

Creates the app card in the Vibecode apps catalog on the Bitrix24 account. Before this call the card appeared only after a successful deployment, so an app brought up any other way was missing from the catalog, and granting access to employees did not surface it.

Editing the access policy or the access list does not create a card — it updates an existing one. Publishing stays a separate action: the card appears in the catalog for the owner and for the employees who already have access.

This is not REST app publishing and not an interface placement — those are POST /v1/apps/:id/publish and placements.

Parameters

The request body may be empty or {}. Unknown fields are ignored.

Examples

curl — personal key

curl -X POST -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" -d '{}' \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/b24-catalog/publish

curl — OAuth application

curl -X POST -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" -d '{}' \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/b24-catalog/publish

JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/b24-catalog/publish`,
  {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_API_KEY', 'Content-Type': 'application/json' },
    body: '{}',
  }
)
const body = await res.json()
if (!body.success) {
  // CATALOG_ALREADY_PUBLISHED means the card is already there — do not repeat
  console.error(body.error.code, body.error.message)
  throw new Error(body.error.code)
}
// The card appears in the catalog after the next synchronization cycle
console.log('Publication queued')

JavaScript — OAuth application

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/b24-catalog/publish`,
  {
    method: 'POST',
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
      'Content-Type': 'application/json',
    },
    body: '{}',
  }
)

Response fields

The publication state is read through GET /v1/infra/servers/:id in the b24CatalogSync block:

A value of eligible: true means "a card is possible", not "publishing will succeed": for an app whose card already exists the call answers 409 CATALOG_ALREADY_PUBLISHED.

Response example

{
  "success": true,
  "data": {
    "queued": true,
    "op": "ADD"
  }
}

Error response example

409 — the catalog card already exists:

{
  "success": false,
  "error": {
    "code": "CATALOG_ALREADY_PUBLISHED",
    "message": "This server already has a Bitrix24 catalog card."
  }
}

Errors

The full list of shared API errors — Errors.

Known specifics

• The call queues a task instead of creating the card. The card is created by background synchronization, so itemId in GET /v1/infra/servers/:id is not filled at response time. Track readiness by polling: b24CatalogSync.itemId stops being null and status becomes SYNCED.
• Repeating the call while the publication is queued is safe. The answer is 200 again and no second card is created.
• A managing key is required. Publishing runs on behalf of the owner of the server's managing key, so a server that lost its key answers 400 CATALOG_NOT_ELIGIBLE. The key is restored in your Vibecode account.
• Granting access does not create the card. The order is: publish first, then the access policy and the access list. The reverse order also works — after publishing, the card picks up the access already granted on the first synchronization.
• Deploy first, publish second. The subdomain is minted when the server is created, and an app only appears on it after a deploy, so a server with no deploy on record returns eligible: false and the call answers 400 CATALOG_NOT_ELIGIBLE. Otherwise the catalog card would lead to an address where nothing answers, and the only way to remove it would be to delete the server. The platform also holds no deploy record when the app arrived not through deploy but via a file upload, a command or SSH — such a server gets 400 CATALOG_NOT_ELIGIBLE too, even though the app is running on it. The only way around is a real deploy, and by default (cleanDeploy) it wipes the app directory, so save whatever is already there first.
• Catalog synchronization can be switched off on the platform side. In that state eligible comes back false and the publish call answers 400 CATALOG_NOT_ELIGIBLE: nothing would process the queue, so the platform refuses up front instead of leaving the card "being added" indefinitely.

See also

• Get a server
• Access policy
• Access list
• Deploy an app