# 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:

```json
{
  "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 to the save method: `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:

```json
{
  "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

A Bitrix24 account administrator can disable source saving in your Vibecode account: the "Settings" administration section, the "Application source autosave" block. 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

| Parameter | Type | Default | Description |
|----------|-----|-----------|----------|
| `page` (query) | number | `1` | Page number. |
| `limit` (query) | number | `25` | Page size, maximum `100`. |
| `search` (query) | string | — | Filter by title / server name / owner name. |

## Examples

### curl — personal key

```bash
curl "https://vibecode.bitrix24.com/v1/me/sources?page=1&limit=25" \
  -H "X-Api-Key: YOUR_API_KEY"
```

### curl — OAuth application

```bash
curl "https://vibecode.bitrix24.com/v1/me/sources?page=1&limit=25" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN"
```

### JavaScript — personal key

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/me/sources?page=1&limit=25', {
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
  },
})

const { data, total } = await res.json()
```

### JavaScript — OAuth application

```javascript
const res = await fetch('https://vibecode.bitrix24.com/v1/me/sources?page=1&limit=25', {
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
  },
})

const { data, total } = await res.json()
```

## Response fields

| Field | Type | Description |
|------|-----|----------|
| `success` | boolean | Always `true` on success. |
| `data` | array | Snapshot owners — servers and legacy apps. The row shape is in the table below. |
| `total` | number | Total number of rows matching the request. |
| `page` | number | Number of the page returned. |
| `limit` | number | Page size the request was processed with. |

The shape of a `data[]` row:

| Field | Type | Description |
|------|-----|----------|
| `kind` | string | `server` or `legacy-app`. |
| `ownerKey` | string | The row's owner ID: the server ID (`kind: server`) or the app ID (`kind: legacy-app`). |
| `title` | string | Display title (server or application). |
| `server` | object \| null | For `kind: server`: `id`, `name`, `displayName`, `mode` in uppercase, `status` in lowercase, `blackholeStatus`, `deleted`. Otherwise `null`. |
| `app` | object \| null | For `kind: legacy-app`: `id`, `title`. Otherwise `null`. |
| `user` | object \| null | Owner: `id`, `name`. May be `null`. |
| `latestVersionId` | string | Identifier of the most recent version (`vN`). |
| `latestSavedAt` | string | Save time of the latest version (ISO 8601). |
| `versionsCount` | number | Number of versions. |
| `totalSizeBytes` | number | Total size of the archives in bytes. |
| `reachableViaApi` | boolean | Whether the record is reachable via the V1 endpoints (see below). |
| `listEndpoint` | string \| null | Ready-to-use path to list the owner's versions, or `null`. |
| `latestDownloadEndpoint` | string \| null | Ready-to-use path to download the latest version, or `null`. |

## Response example

`HTTP 200`:

```json
{
  "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:

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

## Errors

| HTTP | Code | Description |
|------|-----|----------|
| 403 | `PORTAL_KEY_REQUIRED` | The key is not bound to a portal — a management key cannot read the registry. |
| 401 | `MISSING_API_KEY` | The `X-Api-Key` header was not sent. |
| 401 | `INVALID_API_KEY` | The platform did not recognize the key. |

Full list of common API errors — [Errors](/docs/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 only the sources 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 desktop key: it gets `true` for a server that one of the key owner's applications is bound to, as long as the server is not deleted. The pointers lead to the version list and the download. Writing, deleting and cleaning up versions stay closed to this key. 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](/docs/source-storage/retention#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 status stored in the database and updated by the background server monitor (it catches up with a delay of about 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](/docs/source-storage)
- [List versions](/docs/source-storage/versions)
- [Server-keyed source endpoints](/docs/source-storage/servers)
- [Version lifetime and cleanup](/docs/source-storage/retention)
- [Storage](/docs/storage)