## Перевести сделку на другую стадию

`POST /v1/deals/:id/move`

Переводит сделку на другую стадию воронки. Тем же вызовом сделка переносится в другую воронку.

## Параметры

| Параметр | Тип | Обяз. | Описание |
|----------|-----|:-----:|---------|
| `id` (path) | number | да | ID сделки. Список: `GET /v1/deals` |

## Поля запроса (body)

| Поле | Тип | Описание |
|------|-----|---------|
| `stageId` | string | Идентификатор целевой стадии. Список стадий основной воронки — `GET /v1/statuses?filter[entityId]=DEAL_STAGE`, воронки с `categoryId` равным `{N}` — `GET /v1/statuses?filter[entityId]=DEAL_STAGE_{N}` |
| `categoryId` | number | ID целевой воронки. Передаётся вместе со `stageId` из этой же воронки, когда сделка переносится между воронками. Список: `GET /v1/deal-categories` |

Поля вне таблицы игнорируются.

## Примеры

### curl — личный ключ

```bash
curl -X POST "https://vibecode.bitrix24.tech/v1/deals/741/move" \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "stageId": "C1:PREPARATION"
  }'
```

### curl — OAuth-приложение

```bash
curl -X POST "https://vibecode.bitrix24.tech/v1/deals/741/move" \
  -H "X-Api-Key: YOUR_APP_KEY" \
  -H "Authorization: Bearer USER_SESSION_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "stageId": "C1:PREPARATION"
  }'
```

### JavaScript — личный ключ

```javascript
const res = await fetch('https://vibecode.bitrix24.tech/v1/deals/741/move', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_API_KEY',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    stageId: 'C1:PREPARATION',
  }),
})

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

### JavaScript — OAuth-приложение

```javascript
const res = await fetch('https://vibecode.bitrix24.tech/v1/deals/741/move', {
  method: 'POST',
  headers: {
    'X-Api-Key': 'YOUR_APP_KEY',
    'Authorization': 'Bearer USER_SESSION_TOKEN',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    stageId: 'C1:PREPARATION',
  }),
})

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

### Перенос в другую воронку

Тело запроса несёт стадию целевой воронки и её `categoryId`:

```json
{
  "stageId": "C11:NEW",
  "categoryId": 11
}
```

## Поля ответа

| Поле | Тип | Описание |
|------|-----|---------|
| `success` | boolean | `true` при успешном вызове |
| `data` | object | Сделка после вызова, все поля — см. [Поля сделки](/docs/entities/deals/fields) |
| `data.stageId` | string | Стадия сделки после вызова |
| `data.previousStageId` | string | Стадия, на которой сделка была до вызова |
| `data.categoryId` | number | Воронка, в которой сделка находится после вызова |
| `data.movedTime` | string | Момент последней смены стадии в формате ISO 8601 |

## Пример ответа

Показаны основные поля.

```json
{
  "success": true,
  "data": {
    "id": 741,
    "title": "Поставка оборудования",
    "categoryId": 1,
    "stageId": "C1:PREPARATION",
    "previousStageId": "C1:NEW",
    "stageSemanticId": "P",
    "assignedById": 1,
    "movedBy": 1,
    "movedTime": "2026-08-25T10:47:14.000Z",
    "updatedAt": "2026-08-25T10:47:14.000Z"
  }
}
```

## Пример ответа при ошибке

404 — сделки с таким `id` нет:

```json
{
  "success": false,
  "error": {
    "code": "ENTITY_NOT_FOUND",
    "message": "Элемент не найден"
  }
}
```

422 — переданная стадия/воронка не применилась (например, `stageId`, которого нет в справочнике). Запись к этому моменту уже прошла в Битрикс24 и перечитана, поэтому отказ несёт перечитанную сделку в `data`, а `error.details` — список неприменившихся полей и их текущие значения:

```json
{
  "success": false,
  "error": {
    "code": "STAGE_NOT_APPLIED",
    "message": "Bitrix24 accepted the write but did not apply it: stageId requested \"C1:BOGUS\", still \"C1:NEW\" after re-read. The value is likely not a valid id for this deal — check GET /v1/statuses?filter[entityId]=... (or GET /v1/deal-categories for a pipeline id) for the valid set before retrying. The record was already written and re-read: any OTHER field in the same request may have been applied, so correct the value and send only what still needs changing rather than repeating the whole body.",
    "details": {
      "unappliedFields": ["stageId"],
      "currentValues": {
        "stageId": "C1:NEW"
      }
    }
  },
  "data": {
    "id": 741,
    "title": "Поставка оборудования",
    "categoryId": 1,
    "stageId": "C1:NEW"
  }
}
```

## Ошибки

| HTTP | Код | Описание |
|------|-----|---------|
| 404 | `ENTITY_NOT_FOUND` | Сделки с указанным `id` нет |
| 422 | `STAGE_NOT_APPLIED` | Переданная `stageId`/`categoryId` не применилась — после вызова значение осталось прежним (обычно означает несуществующую стадию или воронку). Раньше такой вызов отвечал `200` без предупреждения; теперь — явная ошибка: подробности в `error.message` и `error.details`, перечитанная сделка — в `data` |
| 422 | `BITRIX_ERROR` | Битрикс24 отклонил сам вызов (не конкретно значение стадии) — например неверный формат поля. Текст причины приходит в `error.message`, машиночитаемый код Битрикс24 — в `error.b24Code` |
| 403 | `BITRIX_ACCESS_DENIED` | Битрикс24 отказал в доступе к сделке |
| 403 | `SCOPE_DENIED` | Ключу не хватает скоупа `crm` |
| 403 | `WRITE_BLOCKED_READONLY_KEY` | Ключ в режиме «только чтение» вызвал метод записи |
| 401 | `TOKEN_MISSING` | У ключа нет настроенных токенов авторизации |
| 429 | `RATE_LIMITED` | Превышен лимит запросов. В ответе приходит заголовок `Retry-After` с рекомендованной паузой |

Полный список общих ошибок API — [Ошибки](/docs/errors).

## Известные особенности

- **Пустое тело — не ошибка.** Вызов без `stageId`/`categoryId` в теле отвечает `200`, и сделка остаётся на прежней стадии: сверять нечего, поэтому это не `STAGE_NOT_APPLIED` — платформа проверяет только те поля, что реально были переданы.

## Смотрите также

- [Обновить сделку](/docs/entities/deals/update)
- [Получить сделку](/docs/entities/deals/get)
- [Поля сделки](/docs/entities/deals/fields)
- [Воронки сделок](/docs/entities/deal-categories)
- [Справочники CRM](/docs/entities/statuses)