Для точной оценки нужны описание обмена, документация API и тестовые доступы.
На живом сайте интеграция редко ограничивается одним запросом к API. Нужно проверить поля, обязательные значения, UTM-метки, дубли, статусы, ошибки, таймауты, повторы и уведомления. Иначе заявка может выглядеть отправленной на сайте, но так и не дойти до менеджера.
Перед разработкой важно понять, где именно рождаются данные и куда они должны попасть. Для формы это поля, согласия, файлы, защита от спама и событие отправки. Для каталога — идентификаторы товаров, свойства, цены, остатки, торговые предложения и правила обновления. Для CRM — статусы, ответственный, источник, UTM и обработка дублей.
Если интеграция уже есть, но заявки теряются, сначала полезно пройти диагностику по цепочке. Я описал такой подход в статье почему не приходят заявки с сайта на 1С-Битрикс.
Для сложных обменов интеграцию лучше проектировать вместе с доработкой логики сайта на 1С-Битрикс, а не добавлять отдельным фрагментом поверх старого кода.
Для нормальной оценки нужны не только название CRM или 1С. Важно понимать, какие данные передаются, в каком направлении, как часто, что считается успешной отправкой и что делать при ошибке. Если есть документация API, тестовый доступ, пример запроса или выгрузка полей, это ускоряет работу.
Для форм полезно заранее описать обязательные поля, файлы, согласия, UTM-метки и правила защиты от дублей. Для заказов — статусы, состав заказа, оплату, доставку и логику обновления данных после изменений во внешней системе.
Можно, но лучше хотя бы базовое логирование делать сразу. Без логов сложно понять, где пропала заявка: на сайте, в почте, в CRM или во внешнем API.
Для надежности лучше сохранять заявку на сайте и отдельно отправлять её дальше. Тогда при сбое внешнего сервиса данные не теряются.
В обмене с 1С обычно больше сущностей и правил: товары, цены, остатки, заказы, статусы, идентификаторы, ошибки и повторы. Это нужно проектировать, а не просто отправлять один запрос.
Оставьте контакты, и я свяжусь с вами.