## List applications `GET /v1/applications` Returns the applications of the Bitrix24 account that are visible to the key owner — their own, the ones colleagues shared, or everything together. The selection is paged, and a row carries the same field set as an application card. ## Parameters | Parameter | Type | Req. | Default | Description | |-----------|------|:----:|---------|-------------| | `scope` (query) | string | no | `feed` | Which applications to return: `mine` — your own, `shared` — other people's applications you can access, `feed` — both together. The values are case-sensitive, and an empty `scope=` answers `400 INVALID_SCOPE` just like an unknown one: either omit the parameter or send one of the three values | | `page` (query) | number | no | `1` | Page number, counting from one. A value below one and a non-numeric value are both read as `1` | | `limit` (query) | number | no | `50` | How many applications per page, at most `100`. A larger value is clamped to `100`; `0` and a non-numeric value fall back to `50`; a negative value becomes `1` | Paging is driven by `total`, `page` and `limit` from the response: request pages one after another until the number of rows collected reaches `total`. A page past the end of the selection answers `200` with an empty `data` array rather than an error. Counting pages as `total / limit` is valid only when `truncated` is `false`. On `true`, `total` stops being a full count, there are no pages beyond it, and the remainder is reached through `mine` and `shared`, which have no ceiling. ## Examples ### curl — personal key ```bash curl -H "X-Api-Key: YOUR_API_KEY" \ "https://vibecode.bitrix24.com/v1/applications?scope=mine&limit=20" ``` ### curl — OAuth application ```bash curl -H "X-Api-Key: YOUR_APP_KEY" \ -H "Authorization: Bearer USER_SESSION_TOKEN" \ "https://vibecode.bitrix24.com/v1/applications?scope=mine&limit=20" ``` ### JavaScript — personal key ```javascript const res = await fetch('https://vibecode.bitrix24.com/v1/applications?scope=mine&limit=20', { headers: { 'X-Api-Key': 'YOUR_API_KEY' }, }) const { data: applications, total } = await res.json() applications.forEach(app => { const state = app.activeOperation ? `${app.activeOperation.kind} — ${app.activeOperation.status}` : app.server?.status ?? 'no server' console.log(`${app.name}: ${state}`) }) console.log(`Showing ${applications.length} of ${total}`) ``` ### JavaScript — OAuth application ```javascript const res = await fetch('https://vibecode.bitrix24.com/v1/applications?scope=mine&limit=20', { headers: { 'X-Api-Key': 'YOUR_APP_KEY', 'Authorization': 'Bearer USER_SESSION_TOKEN', }, }) const { data: applications, total } = await res.json() ``` ## Response fields | Field | Type | Description | |-------|------|-------------| | `success` | boolean | Always `true` on success | | `data` | array | Array of applications. An array element and the `data` of a single card have the same shape, and the fields of that shape are described on the [Application card](./get.md) page | | `total` | number | How many applications matched the requested `scope`. On `feed` this is the size of the selection rather than the number of applications on the Bitrix24 account — read `truncated` before counting pages from it | | `page` | number | The number of the page served, already clamped to an allowed value | | `limit` | number | The page size, already clamped to an allowed value | | `truncated` | boolean | Whether the output was cut short. Always present, in every `scope`. `false` — `total` is exact. `true` — `total` is the size of the selection, not how many exist, and there are no pages beyond it | ## Response example ```json { "success": true, "data": [ { "id": "cmsw806qp0001tdskzf6mitka", "name": "Draft with no server", "description": null, "type": "PERSONAL", "iconUrl": null, "createdAt": "2026-08-16T19:51:18.817Z", "updatedAt": "2026-08-16T19:51:18.817Z", "viewerState": "owner", "pinned": false, "author": { "name": "Application author" }, "isEmbedded": true, "openUrl": null, "openTarget": null, "server": null, "sources": { "hasVersions": false, "latestVersionId": null, "latestSavedAt": null }, "activeOperation": null }, { "id": "cmsw806qi0000tdskiw2aegii", "name": "Deal report", "description": "Pipeline summary for the period", "type": "PERSONAL", "iconUrl": null, "createdAt": "2026-08-16T19:51:18.810Z", "updatedAt": "2026-08-16T19:51:18.810Z", "viewerState": "owner", "pinned": false, "author": { "name": "Application author" }, "isEmbedded": false, "openUrl": "https://app-05b67cf7.vibecode.bitrix24.com", "openTarget": "app", "server": { "id": "5cbb50f9-f95f-4ddf-ba3b-b771209cb6fb", "status": "RUNNING", "url": "https://app-05b67cf7.vibecode.bitrix24.com", "kind": "STANDALONE", "reachable": true, "lastDeployedAt": "2026-08-16T19:50:41.302Z" }, "sources": { "hasVersions": true, "latestVersionId": "v2", "latestSavedAt": "2026-08-16T19:41:18.818Z" }, "activeOperation": { "kind": "deploy", "status": "running", "step": "build", "startedAt": "2026-08-16T19:50:33.822Z" } } ], "total": 2, "page": 1, "limit": 50, "truncated": false } ``` ## Error response example 400 — the `scope` value is outside the allowed set: ```json { "success": false, "error": { "code": "INVALID_SCOPE", "message": "scope must be one of: mine, shared, feed" } } ``` ## Errors | HTTP | Code | Description | |------|------|-------------| | 400 | `INVALID_SCOPE` | The `scope` value is not one of `mine`, `shared`, `feed`. An empty value and a different letter case land here too | | 401 | `NO_PORTAL` | The key is not bound to an account — the actual answer for this case | | 403 | `MANAGEMENT_KEY_NO_ENTITY_ACCESS` | A management key: an API key or an authorization key is required | | 403 | `PORTAL_KEY_REQUIRED` | The section's safety net: a damaged key row with no owner. The ordinary "key with no account" is `401 NO_PORTAL` above | | 401 | `MISSING_API_KEY` | The `X-Api-Key` header was not sent | | 401 | `INVALID_API_KEY` | Invalid or expired API key | | 429 | `RATE_LIMITED` | Rate exceeded. 60 requests per minute is the platform-wide limit; one replica's share today is 20 — read `X-RateLimit-Limit` from the response. The counter is per key owner. The limit is stricter than the one for the application card: the list is meant for refreshing a screen, not for polling in a loop. A `Retry-After` header carries the pause in whole seconds | | 429 | `QUOTA_EXCEEDED` | The key's daily free-call quota is exhausted. Same status, different cause: waiting does not help | The `error.message` text is always English and meant for logs: build your interface texts from `error.code`. The full list of common API errors — [Errors](/docs/errors). ## Known specifics - **The selection follows the key owner, not the key itself.** Applications created in the Vibecode dashboard are included too: their servers are bound to other keys of the same person, so [`GET /v1/infra/servers`](/docs/infra/servers/list) cannot see them while this list can. The reverse holds as well — swap the key for a fresh one and the same list comes back. - **Row order depends on `scope`, and it is total.** On `feed` pinned applications come first, then your own, then the ones shared with you, and within each group, applications with a newer `updatedAt` come first. On `mine` and `shared` there is a single order — by `createdAt`, newest first. In both cases ties on the timestamp are broken by `id`, and that matters for walking pages: applications created in a batch carry identical timestamps, and without the secondary key two pages of one walk could overlap or skip an application. - **On `feed` the selection is capped from above, and `truncated` says so.** The order for that list is computed in the service rather than by the database query, so the page is cut after sorting and `total` reports the size of that selection, not the number of applications on the whole Bitrix24 account. Read the flag carefully: it is raised when the selection reached the cap, and reaching the cap cannot be told from "that was exactly all" in one query, so the platform errs toward admitting incompleteness. A false `true` you can diagnose yourself — ask for the next page and get an empty one. A false `false` could not be diagnosed at all, which is why it is not allowed to happen. On `mine` and `shared` there is no ceiling, `total` is the full number of rows matching the filter and `truncated` is always `false`. - **`updatedAt` does not track how fresh the code is.** The field moves when the card itself is updated: a rename, a description change, unlinking a deleted server. A deployment does not move it, so an application deployed ten times today sinks to the tail of `feed`. To see how fresh the code is, read `sources.latestSavedAt`. - **On `shared` and `feed` the source summary is almost always empty.** Both enrichment blocks are filled in only for whoever manages the application, so on other people's rows `sources` arrives empty and `activeOperation` is `null`. The shape of the row does not change, and from the row alone "the data is not disclosed" cannot be told apart from "there are no versions". A screen that renders code status for the whole output has to account for that. - **An empty `shared` is a working state, not a refusal.** A `200` with an empty `data` array and `total: 0` means there are no other people's applications you can access. There is no error to look for in that case. - **`requestable` is never returned in the list — in any `scope`.** The selection only admits applications that are yours, reachable through the server's access policy, opened to you personally by a grant, bound to a server whose development team you belong to, or serverless and open to the whole Bitrix24 account. So this section needs no "request access" affordance — and there would be nowhere to point one: there are no write operations here. The `requestable` value exists for completeness and only surfaces where the card refuses: `403 FORBIDDEN` on a direct request for someone else's closed application. - **`scope` and `viewerState` draw different lines.** Besides the applications shared with you personally, `shared` also covers applications with no server that are open to the whole Bitrix24 account — and such a row arrives with `viewerState: "usable"`, not `"shared"`. A client that filters rows by `viewerState === "shared"` will drop part of the output. ## See also - [Application card](./get.md) - [Application catalog](/docs/applications) - [Servers](/docs/infra/servers) - [Keys and authorization](/docs/keys-auth) - [Limits and optimization](/docs/optimization) - [Errors](/docs/errors)