Operation outcome from the server feed

GET /v1/infra/servers/:id/operations/:operationId

Returns the outcome of a deploy or command that an entry in the server activity feed refers to. The operation is looked up by server ID and operation ID.

Use it when the outcome is read by a key other than the one that started the operation: GET /v1/infra/operations/:operationId responds only to requests made with the key that created the operation, while this endpoint follows the access rule of the activity feed. It is read by the server owner with a personal key or with the key of their OAuth application from the same Bitrix24 account, and by a development team member whose role includes server settings, with their own personal key. An OAuth application key reads the feed with the rights of its owner: the session user does not affect access, and the session token can be omitted. Keys issued for a narrow task with their own route list — the agent maintenance key, the application external API key, the team member key and the external collaborator key — do not read the outcome at this path and get 403 with a code of the form …_KEY_OUT_OF_SCOPE. This response contains only operation metadata. The private durable exec fields stdout, stderr, duration and truncated are absent even for the creator; read them through the authorized scoped endpoint. The metadata response is the same as for GET /v1/infra/operations/:operationId. The endpoint is read-only and has no side effects.

Durable exec is standalone only. async=true accepts a timeout from 1 to 86400 seconds on STANDALONE. Other server kinds receive 400 DURABLE_EXEC_UNSUPPORTED_SERVER_KIND before locking, operation creation or command dispatch, without a synchronous fallback. Galaxy exec stays synchronous with a 600-second limit. A running standalone durable job keeps its execution channel busy after 202; poll this operation rather than resend the command. An unknown outcome needs reconciliation and confirmed termination. /unstick and lock deletion do not remove the restriction on accepting durable jobs.

Parameters

Examples

curl — personal key

curl -H "X-Api-Key: YOUR_API_KEY" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/operations/OPERATION_ID

curl — OAuth application

curl -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  https://vibecode.bitrix24.com/v1/infra/servers/SERVER_ID/operations/OPERATION_ID

JavaScript — personal key

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/operations/${operationId}`,
  { headers: { 'X-Api-Key': 'YOUR_API_KEY' } }
)

if (res.status === 410) {
  console.log('The operation existed, but its details are no longer stored')
} else {
  const { data } = await res.json()
  console.log(`Status: ${data.status}, step: ${data.step}, reason: ${data.error?.code ?? '—'}`)
}

JavaScript — OAuth application

const res = await fetch(
  `https://vibecode.bitrix24.com/v1/infra/servers/${serverId}/operations/${operationId}`,
  {
    headers: {
      'X-Api-Key': 'YOUR_APP_KEY',
      'Authorization': 'Bearer USER_SESSION_TOKEN',
    },
  }
)
const { data } = await res.json()

Response fields

The meaning of the statuses and of the exitCode + status pair is on the Operation outcome page.

Response example

{
  "success": true,
  "data": {
    "operationId": "cmop1abcdefghijklmnopqrs",
    "kind": "deploy",
    "serverId": "8f14e45f-ceea-467a-9c8d-2f1c5a6b7e30",
    "status": "failed",
    "step": "download",
    "startedAt": "2026-10-06T12:13:17.762Z",
    "finishedAt": "2026-10-06T12:13:28.135Z",
    "error": {
      "code": "DOWNLOAD_HTTP_STATUS",
      "message": "The source returned HTTP 404."
    }
  }
}

Error response example

404 — the server does not exist, is not available to this key, or the feed is not yet enabled for the server owner:

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

Errors

For the full list of common API errors, see Errors.

Known specifics

• Someone else's server and a disabled feed give the same 404 SERVER_NOT_FOUND. A separate response would confirm that such a server exists.
• The outcome is readable even for an operation that is not in the feed. The endpoint looks the operation up by server, not by feed entry, so it also answers for a deploy started before the feed was enabled for the server owner — while the outcome is stored.
• OPERATION_NOT_FOUND is returned only to someone who can see the server. An operation of another server is not read at this path, even if both servers are yours. A feed entry has no serverId of its own: take ref.id from the feed of the server whose id is in the request path.

See also

• Server activity feed
• Operation outcome
• Recent server operations
• Service logs