Интеграция сайта с CRM, 1С и API сторонних сервисов

Зачем связывать сервисы между собой

Когда сайт, CRM и учётная система не связаны, сотрудники переносят данные руками: заявки из почты в CRM, заказы в 1С, остатки на маркетплейсы. Это медленно, а главное — приводит к расхождениям: в разных системах разные цифры, часть заявок теряется, клиент получает подтверждение заказа на товар, которого уже нет. Интеграция через API убирает ручной перенос: данные передаются автоматически, в нужном формате и в нужный момент.

Интеграция сайта с CRM: Битрикс24 и amoCRM

Самая частая задача — чтобы заявка с сайта сразу попадала в воронку продаж. Мы передаём не только имя и телефон, но и контекст: с какой страницы пришла заявка, какие UTM-метки были у визита, что клиент написал в комментарии. Менеджер видит источник сделки, а вы — какие каналы реально приносят обращения.

У Битрикс24 и amoCRM открытый REST API, входящие и исходящие вебхуки и авторизация по OAuth 2.0 — этого достаточно и для передачи данных на сторону CRM, и для обратной связи. Настраиваем:

• Создание лида или сделки с заполнением нужных полей, ответственного и воронки.
• Поиск дублей по телефону и почте — повторное обращение прикрепляется к существующему контакту, а не плодит карточки.
• Обратный поток: смена статуса в CRM меняет статус заказа на сайте или в личном кабинете клиента.
• Уведомления: новая заявка одновременно уходит в Telegram менеджеру, чтобы ответить быстрее.

Подробно о том, что даёт бизнесу такая связка, мы разобрали в статье «Зачем бизнесу интеграция сайта с CRM».

Интеграция с 1С

Если товары, цены и остатки живут в 1С, сайт должен брать их оттуда, а не из отдельной таблицы, которую кто-то обновляет вручную. Мы настраиваем обмен в обе стороны: из 1С на сайт уходят номенклатура, характеристики, цены и остатки, а с сайта в 1С — оформленные заказы и данные покупателей.

Способ обмена подбираем под конфигурацию: интерфейс OData, HTTP-сервисы или выгрузка в формате CommerceML. Для типовых конфигураций обычно достаточно штатных механизмов, для доработанных — пишем обмен под вашу структуру данных. Частоту синхронизации выбираем по задаче: остатки ходового товара имеет смысл обновлять каждые несколько минут, а справочник номенклатуры — раз в сутки. Важный момент, который часто упускают: сопоставление товаров между системами должно идти по стабильному идентификатору, а не по названию — иначе после первой же правки в 1С каталог на сайте начинает задваиваться.

Интеграция платёжных систем

Подключаем приём онлайн-оплаты: ЮKassa, эквайринг Т-Бизнеса, оплату через СБП. Схема одна и та же — сайт создаёт платёж, клиент уходит на страницу оплаты, а сервис возвращает результат вебхуком. Тонкости, от которых зависит, будут ли «потерянные» оплаты:

• Проверка подписи уведомления — принимаем только те вебхуки, которые действительно пришли от платёжного сервиса.
• Идемпотентность — повторно доставленное уведомление не создаёт второй заказ и не отправляет второе письмо клиенту.
• Сверка статуса — если вебхук не дошёл, статус платежа перепроверяется запросом к API.
• Возвраты и чеки — оформление возврата из админки и передача данных для фискализации по 54-ФЗ.

Интеграция с маркетплейсами: Wildberries и Ozon

Для продавцов на маркетплейсах основная боль — расхождение остатков между своим складом, сайтом и площадками. Через Seller API Wildberries и Ozon забираем новые заказы, отдаём актуальные остатки и цены, обновляем статусы отгрузки. Учитываем ограничения площадок: лимиты на частоту запросов, задержки в обновлении данных на стороне маркетплейса, разные форматы карточек. Если товаров тысячи, обмен строим пакетно и по расписанию, чтобы не упираться в лимиты и не терять обновления.

Мессенджеры и уведомления

Telegram подключаем через Bot API, WhatsApp — через официального провайдера Business API. Типовые сценарии: мгновенное уведомление менеджеру о новой заявке, напоминание клиенту о записи или оплате, приём сообщений в общий канал, простой бот, который отвечает на частые вопросы и передаёт диалог человеку. Уведомления обычно окупаются быстрее всего: скорость первого ответа напрямую влияет на конверсию заявки в сделку.

Как мы делаем интеграции надёжными

Интеграция ломается не в день запуска, а через три месяца — когда внешний сервис обновил API, сменился токен или сеть подвела в неудачный момент. Поэтому в каждую интеграцию закладываем:

• Повторные попытки и очередь. Если сервис недоступен, данные не теряются, а досылаются позже.
• Идемпотентность. Повторная доставка события не создаёт дубль заказа или сделки.
• Логирование. Видно, что и когда передавалось, с каким ответом — разбор спорной ситуации занимает минуты.
• Оповещения. При серии ошибок приходит уведомление, а не тишина до звонка клиента.
• Тестовый контур. Проверяем на реальных сценариях до того, как включить обмен в рабочей базе.

Что вы получаете

Единые данные во всех системах: заявка сразу в CRM, заказ — в 1С, остатки на сайте и маркетплейсах совпадают со складом, оплата подтверждается автоматически. Ручной перенос и сверка исчезают, вместе с ними — потерянные заявки и продажи того, чего нет в наличии. Если после интеграции остаётся рутина, которую тоже стоит убрать, посмотрите автоматизацию бизнес-процессов — часто это следующий логичный шаг.