# Page template areas

Binds other pages to the areas of a page layout — header, footer, sidebar — reads the bindings, changes them one at a time, and removes them all at once. Removing a binding leaves the pages themselves on the site.

Bitrix24 API: `landing.template.getLandingRef`, `landing.template.setLandingRef`
Scope: `landing`

## Operations

- [Get page template areas](./template-areas-list.md) — `GET /v1/pages/:id/template-areas`
- [Update page template areas](./template-areas-update.md) — `PATCH /v1/pages/:id/template-areas`
- [Clear page template areas](./template-areas-delete.md) — `DELETE /v1/pages/:id/template-areas`

## Key fields

All three methods return one object — the page's own bindings after the call.

| Field | Description |
|------|----------|
| `areas` | Area bindings. The key is the area number as a string, the value is the ID of the page placed in that area. For a page with no bindings of its own, it is an empty object `{}` |
| area number | Signed integer from `-2147483648` to `2147483647`, including `0`. The response returns it in decimal notation: `007` becomes `7` |
| page ID | The ID of any page visible to the user, including a page from another site. Page list: [`GET /v1/pages`](/docs/entities/pages/list) |

## Before you start

1. **The page layout is set by the `tplId` field.** Change the layout with [`PATCH /v1/pages/:id`](/docs/entities/pages/update); the number of areas in each layout is listed on the [Layout templates](/docs/entities/site-templates) page. On write, the area number is not checked against the layout: any number in the allowed range is accepted.
2. **A page and a site have separate area sets.** [Site template areas](/docs/entities/sites/template-areas) are read and written separately. The page response does not include site areas, and clearing page areas does not touch site areas.
3. **An update merges with the current set.** `PATCH` changes only the areas you pass; the value `null` removes the binding from a single area. All bindings can be removed only with `DELETE`: an empty `areas` returns `400`.
4. **Writes are verified by rereading.** After a change, write methods read the areas again and return them. If the change was not saved, the response is `422 BITRIX_ERROR`, not `200`.
5. **One write at a time.** While a write to a page's areas is in progress, a second write to the same areas through the API returns `409 TEMPLATE_AREAS_BUSY` — retry it later. The lock applies only between API requests: it does not account for edits made in the Bitrix24 interface.
6. **A page in a separate scope: knowledge base, group, or the `MAINPAGE` scope.** For such a page, pass the `scope` query parameter with the value `KNOWLEDGE`, `GROUP`, or `MAINPAGE` — without it the page is not found and the response is `404`. For a page on a regular site, do not pass `scope`.

## Typical scenario

1. Find the site's pages: [`GET /v1/pages?filter[siteId]=:id`](/docs/entities/pages/list).
2. Give the page a layout with a header and footer: [`PATCH /v1/pages/:id`](/docs/entities/pages/update) with `{"tplId": 7}`.
3. View the current bindings: [`GET /v1/pages/:id/template-areas`](./template-areas-list.md).
4. Place a header page in an area: [`PATCH /v1/pages/:id/template-areas`](./template-areas-update.md) with `{"areas": {"1": 2387}}`.
5. Publish the page: `POST /v1/pages/:id/publication`.

## Limits

| Limit | Value |
|-------|----------|
| Area number | From `-2147483648` to `2147483647` |
| Concurrent writes | One per page. A second write at the same time returns `409 TEMPLATE_AREAS_BUSY` |
| Request rate | General API limits — [Limits and optimization](/docs/optimization) |

## See also

- [Pages](/docs/entities/pages)
- [Site template areas](/docs/entities/sites/template-areas)
- [Layout templates](/docs/entities/site-templates)
- [Page system roles](/docs/entities/pages/system-pages)
- [Limits and optimization](/docs/optimization)