# Обновить
`POST` `https://api.pushwoosh.com/messaging/v2/update`
Заменяет ранее созданное сообщение, идентифицируемое по его `message_code`, новым определением. Замена является **полной, а не частичной (patch)**: новое определение применяется в точности так, как было отправлено, и `message_code` не изменяется.
Обновление доступно только пока сообщение находится в состоянии ожидания (**pending**) — то есть запланировано для будущей отправки и еще не было взято в обработку или на доставку.
Чтобы проверить, находится ли сообщение в состоянии, допускающем обновление, см. раздел [Проверка статуса сообщения](#checking-message-status).
## Запрос
Аутентифицируйтесь с помощью вашего [токена Server API](/ru/developer/api-reference/api-access-token/#server-api-token) в заголовке `Authorization: Token `.
| Поле | Тип | Обязательно | Описание |
|---|---|---|---|
| `message_code` | string | Да | [Код сообщения](/ru/developer/api-reference/api-identifiers/#message-code) для обновления, возвращаемый методом [`Notify`](/ru/developer/api-reference/messaging-api-v2/notify/) в поле `result.message_code`. |
| `request` | object | Да | Полное новое определение сообщения. Структура такая же, как у тела запроса [`Notify`](/ru/developer/api-reference/messaging-api-v2/notify/) — объект `segment` или `transactional`. Проверяется точно так же, как и `Notify`. |
### Пример запроса
Перепланировать сообщение для сегмента и изменить его содержимое:
```bash
curl -X POST https://api.pushwoosh.com/messaging/v2/update \
-H "Authorization: Token YOUR_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"message_code": "XXXX-XXXXXXXX-XXXXXXXX",
"request": {
"segment": {
"application": "XXXXX-XXXXX",
"platforms": ["IOS", "ANDROID"],
"code": "active_users",
"payload": {
"content": {
"localized_content": {
"en": {
"ios": { "body": "Updated message" },
"android": { "body": "Updated message" }
}
}
}
},
"schedule": { "at": "2026-05-02T12:00:00Z" },
"message_type": "MESSAGE_TYPE_MARKETING"
}
}
}'
```
## Ответ
В случае успеха возвращает HTTP 200 с результатом обновленного сообщения. `message_code` не изменяется.
```json
{
"result": {
"message_code": "XXXX-XXXXXXXX-XXXXXXXX",
"unknown_identifiers": []
}
}
```
- `message_code` (string): тот же код, который был передан в запросе.
- `unknown_identifiers` (array of string): идентификаторы в новом определении, которые не были найдены, если применимо (см. [`Notify`](/ru/developer/api-reference/messaging-api-v2/notify/)).
## Ошибки
Ошибки используют стандартную оболочку ошибок gRPC-Gateway: `{ "code": ..., "message": ..., "details": [...] }`.
| HTTP-статус | Условие |
|---|---|
| `400` | Отсутствует `message_code`. |
| `400` | Новое определение `request` отсутствует или недействительно (проверяется точно так же, как и в [`Notify`](/ru/developer/api-reference/messaging-api-v2/notify/)). |
| `400` | Сообщение не находится в состоянии, допускающем обновление (оно больше не в состоянии ожидания - `pending`). |
| `403` | Сообщение принадлежит другому аккаунту. |
| `404` | Сообщение с указанным `message_code` не существует. |
| `500` | Произошла внутренняя ошибка при загрузке сообщения или применении обновления. Повторите запрос. |
**Пример**
Обновление несуществующего сообщения вернет HTTP `404`:
```json
{
"code": 5,
"message": "message not found",
"details": []
}
```
## Проверка статуса сообщения
Перед обновлением вы можете проверить, находится ли сообщение в состоянии, допускающем обновление. Помимо просмотра столбца **Статус** в таблице сообщений в Control Panel ([**Кампании → Разовые сообщения**](/ru/product/statistics-and-analytics/message-history/)), вы можете запросить статус программно с помощью [`messages:list`](/ru/developer/api-reference/statistics-api/message-statistics-api/#messageslist):
- Передайте `message_code` в массиве `filters.messages_codes` (вместе с обязательным `filters.application`).
- Прочитайте поле `status` соответствующей записи в `items[]`.
## Связанные материалы