Source registry and Bitrix24 account state

Where to see every deposited snapshot at once — the page in your Vibecode account and its API counterpart GET /v1/me/sources. Plus a programmatic check of whether source saving is enabled for your Bitrix24 account.

Checking Bitrix24 account state

GET /v1/me returns the data.capabilities.apps.sourceStorage block:

When saving is enabled:

{
  "capabilities": {
    "apps": {
      "sourceStorage": {
        "enabled": true,
        "requiredBeforeDeploy": false,
        "automaticOnDeploy": true,
        "limits": {
          "maxBlobBytes": 524288000
        },
        "endpoint": "POST /v1/apps/:id/sources",
        "mcpToolName": "save_sources",
        "contentTypes": [
          "application/gzip",
          "application/x-tar",
          "application/zip",
          "application/octet-stream"
        ],
        "docs": "https://vibecode.bitrix24.com/docs-content-en/source-storage.md"
      }
    }
  }
}

Alongside the limits, the block also returns pointers on how to save: endpoint, mcpToolName, the allowed contentTypes, and the URL of this documentation.

The freshnessWindowMinutes field is present in this block only while publishing verifies the snapshot's age. Its absence reads as "the age is not checked", so the fields the block carries tell you which rule applies to your Bitrix24 account.

When saving is disabled:

{
  "capabilities": {
    "apps": {
      "sourceStorage": {
        "enabled": false,
        "requiredBeforeDeploy": false,
        "automaticOnDeploy": false,
        "disabledBy": "platform",
        "readOperations": "available",
        "reactivation": {
          "scope": "platform",
          "permission": "platform admin"
        }
      }
    }
  }
}

The two field sets are mutually exclusive: with enabled: false the block carries no pointers to saving. The disabledBy field is "platform" (the feature is not enabled at the platform level) or "portal" (the Bitrix24 account owner disabled it). The readOperations: "available" field means that listing versions and downloading remain available even when saving is disabled. The reactivation block indicates at which level (platform or Bitrix24 account) the feature is turned back on and which permissions that requires.

Disabling for a Bitrix24 account

The Bitrix24 account owner can disable source saving via the administration section (PATCH /api/admin/source-storage with the body { "sourceStorageEnabled": false }, requires an administrator session). When disabled:

• POST /v1/apps/:id/sources returns 200 { skipped: true, reason: "DISABLED_FOR_PORTAL" }.
• POST /v1/apps/:id/publish does not check for a snapshot.
• GET /v1/apps/:id/sources continues to return previously saved versions.
• GET /v1/apps/:id/sources/:versionId/download remains available.

The save history survives re-enabling — previously created versions remain available.

Source registry

The "App sources" page is available in your Vibecode account via the left menu (the package icon). It shows a consolidated list of all deposited snapshots — so you can hand the code over to a new developer or resume an AI session.

Who sees what:

• Bitrix24 account member (MEMBER) — only their own snapshots (the ones they uploaded).
• Bitrix24 account administrator (ADMIN) — all snapshots in the Bitrix24 account, including other members' snapshots. Can download any snapshot.

How to download:

1. Open "App sources" in the menu.
2. Find the row you need (server or application).
3. In the row menu, choose "Download latest version" — the browser downloads the archive.

Application rows carry a "Version history" item in the row menu — it opens the application's version history page in the "Storage" section.

Note: the page works regardless of whether source deposit is enabled at the platform level — historical snapshots are available even if new saves are temporarily disabled.

Aggregated source registry

GET /v1/me/sources

The API counterpart of the "App sources" page in your Vibecode account. Returns a list of source-snapshot owners (servers and legacy apps) across everything the calling key owns. A Bitrix24 account administrator (ADMIN) key sees the whole Bitrix24 account.

Requires an API key bound to a Bitrix24 account. A management key or a key with no account binding → 403 PORTAL_KEY_REQUIRED.

Parameters

Response fields

The shape of a data[] row:

Response example

HTTP 200:

{
  "success": true,
  "data": [
    {
      "kind": "server",
      "ownerKey": "8de64f8d-...",
      "title": "Prod",
      "server": {
        "id": "8de64f8d-...",
        "name": "srv-prod",
        "displayName": "Prod",
        "mode": "BLACKHOLE",
        "status": "sleeping",
        "blackholeStatus": "DISCONNECTED",
        "deleted": false
      },
      "app": null,
      "user": { "id": "8f1a2b3c-...", "name": "Alex" },
      "latestVersionId": "v4",
      "latestSavedAt": "2026-05-21T10:15:30.000Z",
      "versionsCount": 4,
      "totalSizeBytes": 552960,
      "reachableViaApi": true,
      "listEndpoint": "/v1/infra/servers/8de64f8d-.../sources",
      "latestDownloadEndpoint": "/v1/infra/servers/8de64f8d-.../sources/v4/download"
    }
  ],
  "total": 1,
  "page": 1,
  "limit": 25
}

Error response example

401 — the key was not recognized:

{
  "success": false,
  "error": {
    "code": "INVALID_API_KEY",
    "message": "Invalid API key"
  }
}

Errors

Full list of common API errors — Errors.

Known specifics

• reachableViaApi. The field answers one question: will the CALLING KEY be admitted through the V1 drill-in. The value is false in five cases:

  • A server whose managing key was deleted — an orphan record. The drill-in returns 404.
  • A soft-deleted legacy app.
  • A server, when the request is made with an OAuth application key: such a key opens the sources only of the server it owns itself, even when the server was created with your personal key. The drill-in returns 403 NOT_AUTHORIZED.
  • An application row, when the request is made with the key of another application: an application key opens only its own application, even when both applications have the same author. The drill-in returns 403 SOURCE_APP_ID_MISMATCH — that refusal arrives before the authorship check, so it has a code of its own.
  • A server created with another of your personal keys, when your key does not belong to the application bound to that server. This happens even to a Bitrix24 account administrator. The drill-in returns 404.

  Such rows have listEndpoint and latestDownloadEndpoint equal to null, but the row itself stays in the list so that you can see these sources. Check reachableViaApi before following listEndpoint.

  The exception to the last case is the Cowork/Code desktop key: it gets true for a server that an application of the key owner is bound to, as long as the server is not deleted. The pointers lead to the version list and the download. A deleted server stays true for its managing key and for a Bitrix24 account administrator when the server belongs to another user: read and cleanup operations on its versions keep working — Versions of a deleted server.

• Server status. For a Black Hole server, status: "sleeping" is the normal "parked" state (the server wakes on demand), not a failure. Pair it with blackholeStatus to tell "parked, wakes on demand" from a real problem. The value is the fleet-poller-maintained DB status (eventually consistent, ~15 s), not the result of a live check against the provider.

• Contrast with GET /v1/infra/servers. That list is scoped strictly to the calling key's servers, so a server bound to another of the owner's keys is absent there but present in this registry — with reachableViaApi: false when your key does not belong to the application bound to that server.

See also

• Source code storage
• Version list and download
• Server-keyed source endpoints
• Version lifetime and cleanup
• Storage