Сообщения Avito можно получать событийным способом или регулярным опросом API, если этот вариант соответствует текущей документации и аккаунту. В DOLOROSA мы выбрали polling свежих чатов: на аккаунте уже работали сторонние подписки, а ответ всё равно должен был выдержать паузу для менеджера. Оплаченный заказ не определялся только по тексту в чате. Его статус подтверждал Order Management API.
Когда подходит webhook
Webhook удобен, когда нужна быстрая реакция и площадка гарантирует нужное событие. Сервер принимает HTTP POST, быстро проверяет запрос, сохраняет идентификатор события и отвечает. Тяжёлая обработка выполняется в очереди.
Базовый обработчик выглядит так:
def receive_event(payload, headers):
verify_request(headers, payload)
event_id = stable_event_id(payload)
if already_seen(event_id):
return 200
save_event(event_id, payload)
enqueue(event_id)
return 200Конкретный способ проверки подписи и набор событий нужно брать из актуальной документации Avito. Старый код проекта не считается вечным правилом площадки.
Когда polling проще
Polling полезен, когда задержка в несколько секунд допустима, события легко найти по времени обновления, а webhook конфликтует с существующим контуром. Сервис запрашивает список свежих чатов, затем читает только изменившиеся.
В DOLOROSA цикл выглядел так:
GET свежие чаты
→ сравнить updated и локальное состояние
→ GET сообщения изменившегося чата
→ обработать новые ID
→ сохранить cursor/stateЧтение полного архива каждого чата в каждом цикле создаёт лишнюю нагрузку. Код ограничивал окно и хранил обработанные сообщения.
Дубли возможны в обоих вариантах
Webhook может повторить событие, а polling перечитать сообщение после перезапуска. Поэтому состояние строится вокруг внешнего ID, а не текста.
Отдельная проблема возникает после POST. Если сервер площадки принял ответ, но соединение оборвалось, слепой повтор создаст дубль. В Avito-канале отправка помечена как неидемпотентная. Перед повтором чат перечитывается, и система ищет собственное сообщение, появившееся после начала вызова.
Системное сообщение не является статусом заказа
Текст «у вас новый заказ» удобен как сигнал, но бизнес-решение требует отдельной проверки. DOLOROSA обращается к:
GET /order-management/1/ordersОтвет содержит статус и связь с чатом. На его основе Telegram-хаб показывает карточку заказа менеджеру.
Изменение статуса выполняется отдельным методом. В текущем проекте переход подтверждает человек. Агент не принимает и не отклоняет заказ самостоятельно.
Связать заказ и диалог
Поток выглядит так:
системное сообщение или очередной опрос
→ загрузить свежие заказы
→ найти chatId в позиции заказа
→ сравнить статус с сохранённым
→ создать или обновить Telegram-карточку
→ ждать действия менеджераСостояние хранит уже обработанные переходы. Перезапуск сервиса не должен повторно сообщать клиенту старый статус.
Что логировать
Достаточно внешнего ID в обезличенном виде, типа события, старого и нового статуса, результата проверки и причины отказа. Содержимое переписки, адрес, телефон и токены в технический журнал не копируются.
Отдельно считаются:
- задержка между событием и обработкой;
- повторные события;
- неопределённые результаты POST;
- ошибки лимита;
- случаи, когда менеджер ответил раньше агента.
Набор тестов
Проверьте новое сообщение, несколько сообщений подряд, повтор события, перезапуск, длинный чат, таймаут после отправки, новый заказ, отмену и устаревший статус. Для webhook добавьте неверную подпись и медленный обработчик. Для polling проверьте cursor и окно старта.
Выбор между webhook и polling зависит от методов, доступных конкретному аккаунту, и допустимой задержки. Перед выбором транспорта мы составляем карту событий и проверяем актуальную документацию аккаунта.
Читайте также: Как связать Avito, МойСклад и Telegram без потери контекста, Как подключить ИИ-агента к Avito через API.
Источники
- Avito для бизнеса: avito.akamaized.net/business/tools/messenger (проверено 28.09.2026).