Webhooks между CRM и рекламой ломаются не на API, а на логике полей и статусов

Webhooks между CRM и рекламой ломаются не на API, а на логике полей и статусов

Если лид приходит в CRM, а обратно в кабинет уходит пустой или неверный статус, алгоритм начинает обучаться на шуме. Типовые точки отказа:
— разные ID лида в CRM и ad platform;
— отсутствие маппинга статусов «создан», «квалифицирован», «сделка»;
— дубль события при повторной отправке webhook;
— потеря UTM, gclid, fbclid на этапе записи в CRM.

Надежная схема строится не вокруг одного webhook, а вокруг очереди и валидации. Сначала фиксируйте источник, campaign_id, adset_id, lead_id, timestamp и event_type. Затем проверяйте, существует ли запись, не отправляли ли это событие ранее, и только после этого обновляйте статус. Иначе одна повторная доставка создаст ложный «успешный» конверсионный сигнал.

Отдельно проверьте обратную связь в кабинет: событие должно уходить только на тот этап, который реально влияет на оптимизацию. Не перегружайте алгоритм микростатусами вроде «перезвонили» и «не дозвонились» — они полезны в CRM, но вредны в оптимизации. Для рекламы важны 2-4 опорных события, а не вся воронка.

Автоматизируем рутину, масштабируем результат. Если webhook не проходит проверку на идемпотентность, логирование и маппинг статусов, его нельзя считать рабочим, даже если в тесте всё «зеленое».