Разбирайте воронку Битрикс24 и находите потерянные лиды

Агент обращается к порталу через входящий вебхук: его URL уже содержит и адрес, и ключ, поэтому запросы идут REST-методами вроде crm.deal.list прямо в ваш Битрикс24 — облачный или коробочный. Он читает сделки, лиды, контакты, компании и счета, считает конверсию по стадиям, активность менеджеров за период и суммы закрытий. Длинные списки забираются страницами, а о создании и изменении сделок портал может присылать события сам — тогда реакция не ждёт следующего опроса.

Воронка в Битрикс24 разорвана надвое: лид и сделка — разные сущности, и при конвертации из лида рождаются сразу сделка, контакт и компания. Считать конверсию по одним сделкам значит потерять верх воронки, поэтому агент связывает лид с тем, во что он превратился. Стадии тоже не универсальны: у каждого направления сделок свой набор, а часть смысла лежит в пользовательских полях — их агент читает вместе со стандартными.

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

Ссылка вебхука хранится зашифрованной и отзывается в том же разделе «Разработчикам → Другое»; отдельной авторизации портал не требует — ключ едет внутри URL каждого запроса. Частоту запросов агент держит невысокой: лимит портала делится со всеми интеграциями сразу, поэтому длинные выборки он проходит страницами, а не одним махом. Если метод закрыт правами или сделок за период не было, он скажет это прямо, а не отдаст пустую таблицу.