Автоматическую публикацию объявлений начните с устойчивой связи между своим объектом и размещением на площадке. Одному объекту в согласованном канале соответствует определённая запись размещения. Если ответ на создание потерялся, сначала ищите результат через предусмотренный механизм площадки, а не создавайте объявление ещё раз.
Автоматизация допустима через разрешённый способ интеграции и для материалов, которыми вы вправе распоряжаться. Она не должна обходить модерацию, ограничения аккаунта или правила площадки. Для первой проверки нужен разрешённый тестовый контур либо согласованный безопасный объект; рабочие объявления клиентов для эксперимента не подходят.
Объект каталога живёт дольше одного запроса
Пример записи размещения:
source_id: DEMO-17
channel: согласованная площадка
account_scope: тестовый аккаунт
external_id: <после подтверждённого создания>
source_revision: <версия материала>
state: draft / pending / active / rejected / withdrawnЭто внутренняя модель, не универсальные названия статусов API. Уточните, допускается ли несколько размещений одного объекта по городам или аккаунтам. Тогда область связи включает эти признаки. Нельзя определять существующее объявление только по совпадению заголовка: редактор изменит название, и поиск решит, что перед ним новый объект.
Когда использовать создание, а когда изменение
| Ситуация | Действие интеграции | Контроль |
|---|---|---|
| Подтверждённой связи ещё нет | Создание по контракту площадки | Сохранить внешнюю связь |
| Связь есть, материал изменён | Обновление существующего объекта | Сравнить версию |
| Исходник больше не актуален | Согласованное снятие | Подтвердить состояние размещения |
| Исход ответа неизвестен | Выяснение результата | Не начинать новое создание вслепую |
Подготовьте отдельно опубликованную и желаемую версии. Пока площадка обрабатывает правку, интерфейс вашей системы должен показывать это ожидание, а не объявлять новый текст действующим. При отказе сохраните причину и сам черновик: исправление редактором не должно терять исходную связь с размещением.
Ответ транспорта и результат материала
Конкретный пример: документация Яндекс Маркета для updateOfferMappings требует читать status, errors и warnings; HTTP 200 сам по себе не подтверждает корректность всех значений. Источник проверен 11 октября 2026 года. Для объявлений другой платформы формат и последствия ошибок нужно брать из её собственного метода, а не переносить схему Маркета.
Сохраняйте результат операции до подтверждения задания очереди. После аварии процесс должен знать, что отправлял и что получил. При тайм-ауте используйте доступный статус операции, поиск по своему устойчивому ключу или ручной разбор. Если площадка не предоставляет надёжного способа выяснить создание, безопаснее остановить эту запись, чем обещать отсутствие дублей.
Снятие требует собственного правила
Отсутствие объекта в очередном неполном файле ещё не означает команду снять объявление. Источник мог не дочитаться или временно вернуть пустой набор. Прежде чем ставить снятие в очередь, подтвердите полноту выборки и явное состояние объекта. Для больших изменений полезен отчёт будущих действий, который утверждает ответственный.
- Создать тестовое размещение и сохранить связь.
- Повторить обработку той же версии: нового объявления нет.
- Изменить материал: обновляется прежнее размещение.
- Имитировать потерю ответа: запись уходит на выяснение результата.
- Передать неполную выборку: действующие объявления не снимаются массово.
Автопубликация становится управляемой, когда видны желаемая версия, подтверждённое состояние и причина остановки. Для разработки подготовьте правила одного и нескольких размещений, способ проверки неизвестного результата и договорённость о снятии. Именно эти решения определяют надёжность, а не расписание «отправлять каждый час».