# AI site generation

Create a site from a text brief and read its generation state.

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

## Operations

- [Start a site generation](./ai/generate.md) — `POST /v1/sites/ai/generate`
- [Get a generation status](./ai/status.md) — `GET /v1/sites/ai/status`
- [List generation fields](./ai/fields.md) — `GET /v1/sites/ai/fields`
- [Get a generation field](./ai/field.md) — `GET /v1/sites/ai/fields/:name`

## Access

Requests run as the webhook owner or the user whose OAuth token the key uses. A generation belongs to that Bitrix24 user, and only that user can read it. A READONLY key can read field definitions; starting a generation and checking its status require a key that permits writes. Availability and request validation are determined by Bitrix24.

## Draft and repeated requests

Starting a generation takes the user's only available AI site draft. An open AI site chat loses that draft and must be reloaded. A non-empty `Idempotency-Key` is forwarded unchanged. An empty or whitespace-only header is treated as absent. Bitrix24 remembers the completed response for 24 hours; a repeat sent before that response is stored is not protected. Without the header, every call starts another generation.

Bitrix24 automatically attempts to publish the generated site. Include only information intended for public viewing in the description.

Reading a completed or failed generation can make Bitrix24 finalize or release the draft binding and record a moderation refusal. Checking the status therefore requires write access; a READONLY key receives `403 WRITE_BLOCKED_READONLY_KEY`. The platform does not retry a status request after a 5xx error.

## See also

- [Sites](../sites.md)
