Если переписка Яндекс Маркета загружается в CRM, но карточка заказа больше не открывается, проверьте источник идентификатора заказа. В документации получения чата верхнеуровневое поле orderId помечено устаревшим с датой отключения 19 октября 2026 года. Вместо него указано использовать объект context. Это повод проверить интеграцию, а не утверждение, что каждый магазин уже столкнулся со сбоем.

Что изменилось в структуре связи

Контекст различает ORDER, RETURN и DIRECT. В нём orderId и campaignId возвращаются для разговоров по заказам и возвратам, а returnId — только для возвратов. Прямое обращение покупателя имеет другой смысл: его нельзя автоматически объявлять повреждённым заказом из-за отсутствия ожидаемого номера.

Старый обработчик мог считать обязательным orderId на верхнем уровне ответа. После перехода он продолжит получать успешный ответ и текст переписки, но потеряет связь с учётной карточкой. Поэтому проверки одного HTTP-статуса недостаточно: важно проверить отображение правильного заказа в рабочем интерфейсе оператора.

Как найти зависимость от старого поля

Сопоставьте реальный ответ метода получения чата с данными, сохранёнными в CRM. Найдите место, где извлекается номер заказа, и проверьте путь до значения. Просмотрите также выгрузки, шаблоны ссылок и правила распределения обращений: зависимость часто находится не только в основном загрузчике сообщений.

Перед изменением сохраните несколько обезличенных контрольных примеров разных типов. Нужны разговор о заказе, обращение о возврате и прямой диалог. Для каждого определите ожидаемое поведение: какую карточку открыть и какие поля допустимо оставить пустыми. Не создавайте фиктивный номер заказа, чтобы пройти старую обязательную проверку.

Как проверить перенос данных

Новый обработчик должен сначала учитывать тип контекста, затем читать относящиеся к нему идентификаторы. Номер возврата не заменяет номер заказа: оба могут понадобиться для понимания спора. Имя покупателя также не подходит для автоматической привязки — совпадение отображаемых имён не доказывает принадлежность обращения одному заказу.

Проверьте не только новые диалоги, но и повторную загрузку уже существующих. Смена структуры не должна создавать дубликат обращения. Общая организация очереди описана в руководстве по чатам Маркета; здесь критична сохранность связи между прежним chatId и корректно разобранным контекстом.

Как подтвердить исправление в работе

Откройте контрольные диалоги глазами оператора. Проверьте магазин, заказ, возврат и доступность переписки. Отдельно убедитесь, что прямой вопрос покупателя остаётся доступным для ответа без искусственного присоединения к последней покупке. Это важнее формальной успешности обработки JSON.

Если сотрудник отправляет документы, проверьте и привязку вложения к нужному чату. Исправленная ссылка на заказ не должна менять адресата файла. Технические идентификаторы следует проверять до действия, особенно когда в одном кабинете работает несколько магазинов.

После обновления наблюдайте число диалогов без привязки с разбивкой по типу контекста. Для DIRECT отсутствие заказа может быть ожидаемым, для ORDER — основанием расследовать конкретный ответ. Единый тревожный счётчик без такой разбивки создаёт лишние обращения и мешает увидеть настоящую ошибку.

Документация проверена 21 октября 2026 года. Дата 19 октября приводится как заявленный срок отключения поля; фактическое состояние конкретной интеграции устанавливают по её ответам и проверке интерфейса.