# Pages

Managing landing and online-store pages on the Bitrix24 platform: create, get, update, delete. A page always belongs to a site and inherits its type, `PAGE` or `STORE`.

Bitrix24 API: `landing.landing.*`
Scope: `landing`

## Operations

- [Create a page](./pages/create.md) — `POST /v1/pages`
- [List pages](./pages/list.md) — `GET /v1/pages`
- [Get a page](./pages/get.md) — `GET /v1/pages/:id`
- [Update a page](./pages/update.md) — `PATCH /v1/pages/:id`
- [Delete a page](./pages/delete.md) — `DELETE /v1/pages/:id`
- [Search pages](./pages/search.md) — `POST /v1/pages/search`
- [Page fields](./pages/fields.md) — `GET /v1/pages/fields`
- [Aggregate pages](./pages/aggregate.md) — `POST /v1/pages/aggregate`

## Key fields

| Field | Type | Description |
|------|-----|---------|
| `id` | number | Page identifier (read-only) |
| `title` | string | Page title, up to 255 characters. Required on creation |
| `code` | string | Symbolic code of the page in the URL. If omitted, generated from `title`. Must not contain `/`. Must be unique within a site or folder — otherwise a numeric suffix is added automatically |
| `siteId` | number | Identifier of the site the page belongs to. Source: [`GET /v1/sites`](/docs/entities/sites/list). Required on creation |
| `active` | boolean | Whether the page is active. Managed only in the Bitrix24 account interface: new pages are created inactive, and this cannot be changed via the API |
| `description` | string \| null | Arbitrary page description. Comes as `null` if not set (in the operational docs [get](./pages/get.md) / [list](./pages/list.md) the type is already `string \| null` — aligned to them here for consistency) |
| `createdById` | number | Identifier of the employee who created it (read-only). Source: [`GET /v1/users`](/docs/entities/users) |
| `dateCreate` | datetime | Creation date (read-only) |
| `dateModify` | datetime | Last modification date (read-only) |

## What you need to know before working

1. **The request body is flat.** On creation and update, pass fields directly at the root of the JSON: `{"title": "...", "code": "...", "siteId": 3}`. No `fields` wrapper is needed.
2. **Minimum for creation:** `title` + `siteId`. The remaining fields are optional.
3. **The `active` field is not managed via the API.** On creation a page gets `active: false`. Passing `active: true` in `POST` or `PATCH` is accepted without error, but the value is not saved. You can activate a page in the Bitrix24 account interface, under "Sites".
4. **Full field list — [`GET /v1/pages/fields`](./pages/fields.md).** The endpoint returns a map of all page fields with their type and a `readonly` flag. Key fields are listed in the "Key fields" section above, and the full list of 27 fields is on the [Page fields](./pages/fields.md) page.
5. **The response may contain additional Bitrix24 fields — in camelCase.** In addition to the key fields, additional ones are returned by default — in **camelCase**, **not** in `UPPER_CASE`: `deleted`, `xmlId`, `tplId`, `sitemap`, `folder`, `folderId`, `searchContent`, `modifiedById`, `domainId`, `initiatorAppCode`, `rule`, `public`, `sys`, `views`, `tplCode`, `version`, `historyStep`, `datePublic` and others. Reading by the documented name `data[].XML_ID` / `MODIFIED_BY_ID` returns `undefined` — use camelCase. To get only the key fields, pass the `select` parameter in `GET /v1/pages`: `?select=id,title,code,siteId,active,description,createdById,dateCreate,dateModify`. See examples in [List pages](./pages/list.md). For `GET /v1/pages/:id` the `select` parameter does not apply — field selection is available only in the list.
   - The undocumented `datePublic` field of an unpublished page comes as an empty object `{}` (an artifact of Bitrix24 serializing an empty date), not as a date/`null`.
6. **`offset` for pagination is supported.** Vibecode returns the requested `[offset, offset + limit)` window. The `meta.total` value is the exact number of records matching the filter. For large selections `limit > 50` also works.
7. **Sorting is supported.** `?order[field]=asc|desc` or the short form `?sort=-field` (descending), and in the [`POST /v1/pages/search`](./pages/search.md) body the `sort` field. Without a parameter the selection is ordered by ascending `id`. To count the number of pages, use `meta.total` from [List pages](./pages/list.md): `GET /v1/pages?filter[siteId]=3&limit=1` returns `meta.total` without fetching records.

## Related entities

| Entity | Endpoint | Purpose |
|----------|----------|-----------|
| Sites | [`GET /v1/sites`](/docs/entities/sites) | Page containers. Source of `siteId` for creating a page. A site can be deleted only after all its pages are deleted. |

## Typical scenario

1. Find a site: [`GET /v1/sites`](/docs/entities/sites/list).
2. View its pages: [`GET /v1/pages?filter[siteId]=3`](./pages/list.md).
3. Create a new one or update an existing one: [`POST /v1/pages`](./pages/create.md) / [`PATCH /v1/pages/:id`](./pages/update.md).
4. Delete the unneeded ones: [`DELETE /v1/pages/:id`](./pages/delete.md).

## Limits

| Limit | Value |
|-------|----------|
| Maximum records per request | 5000 (`limit ≤ 5000`) |
| Pagination | via `offset` — the `[offset, offset + limit)` window |
| `offset` | supported — the `[offset, offset + limit)` window is applied on the Vibecode side |
| Batch requests | up to 50 operations in [`POST /v1/batch`](/docs/batch) |
| Rate limit | shared across the Vibecode API — see [Limits and optimization](/docs/optimization) |

## See also

- [Sites](/docs/entities/sites) — managing the sites that pages belong to
- [Entity API](/docs/entity-api) — general principles of working with entities
- [Filtering syntax](/docs/filtering)
- [Batch](/docs/batch) — bulk operations
- [Entities reference](/docs/entities-index)