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 enabled and which permissions are required.

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 will download 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 for a server whose managing key was deleted (an orphan record); for a soft-deleted legacy app; for a server when you call with an OAuth application key — such a key opens only the source doors of the server it owns itself, even when the server was created with your own personal key; and for an application row when you call with the key of a DIFFERENT application — an application key is access to one specific application, and authorship does not extend it. Such rows have listEndpoint and latestDownloadEndpoint equal to null. The row is still listed for visibility, but the drill-in returns 404 (orphan record), 403 NOT_AUTHORIZED (an application key on a server it does not own) or 403 SOURCE_APP_ID_MISMATCH (an application key on the row of a DIFFERENT application — that refusal arrives before the authorship check, so it carries its own code). Check reachableViaApi before following listEndpoint. A soft-deleted server stays true: listing and cleanup of 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.

See also

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