Интеграции через API: CRM, склады, сервисы доставки

Сайт, который живёт отдельно от остальных систем компании, создаёт ручную работу: менеджеры копируют заявки в CRM, кладовщик сверяет остатки с витриной, оператор вбивает адреса в личный кабинет службы доставки. Интеграции через API убирают эту рутину и ошибки, которые она порождает. Мы подключаем сайты к 1С, МойСклад, amoCRM, Битрикс24, платёжным сервисам, СДЭК, Boxberry и Почте России, и в этой статье расскажем, как это устроено и на что обратить внимание при заказе.

Что такое API и как через него общаются системы

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

Обмен через API бывает двух типов. В первом сайт сам обращается к внешнему сервису, когда ему что-то нужно: рассчитать доставку, создать сделку в CRM, проверить статус оплаты. Во втором внешний сервис сам уведомляет сайт о событиях через так называемые вебхуки: «оплата прошла», «заказ передан курьеру», «менеджер сменил статус сделки». Хорошая интеграция обычно сочетает оба подхода, чтобы данные обновлялись быстро и не терялись.

Отдельно стоит упомянуть обмен файлами по расписанию — например, выгрузку каталога из 1С в формате CommerceML. Формально это не всегда API в узком смысле, но по задачам он решает то же самое: синхронизирует данные между системами без участия человека.

Какие интеграции нужны чаще всего

Типичный интернет-магазин после запуска использует четыре–шесть интеграций одновременно. Каждая из них по отдельности несложна, но вместе они образуют цепочку, в которой сбой одного звена может остановить продажи. Поэтому важно не только подключить сервисы, но и спроектировать, как они взаимодействуют.

Как выглядит путь заказа при хорошей интеграции

1. Покупатель видит актуальные данные

   Цены и остатки на сайте обновлены из учётной системы 15 минут назад. В корзине рассчитана доставка до его города через API службы доставки, на карте показаны ближайшие пункты выдачи.

2. Оплата проходит онлайн

   Платёжный сервис сообщает сайту об успешной оплате через вебхук, статус заказа меняется на «Оплачен», покупатель получает письмо и электронный чек.

3. Заказ попадает в учёт и CRM

   В 1С или МойСклад создаётся документ заказа с резервом товара, в CRM — сделка с контактом покупателя и источником перехода.

4. Склад собирает и отгружает

   После сборки в службе доставки автоматически создаётся отправление, сайт получает трек-номер и отправляет его покупателю.

5. Статусы синхронизируются

   Служба доставки сообщает о движении посылки, сайт и CRM обновляют статусы, покупатель видит их в личном кабинете.

В этой цепочке ни один сотрудник не переносит данные вручную. Менеджеры занимаются нестандартными ситуациями и общением с клиентами, а не копированием. Для магазина с 50 заказами в день это экономия одной–двух ставок оператора и почти полное исчезновение ошибок в адресах и суммах.

Где интеграции ломаются

Нет обработки ошибок

Внешний сервис временно недоступен, сайт отправил запрос и не получил ответа. Если интеграция написана «в лоб», заказ просто не попадёт в CRM, и никто об этом не узнает. Правильно — сохранять неотправленные данные в очередь, повторять попытки с интервалом и уведомлять ответственного, если отправить не удалось за разумное время.

Нет единого идентификатора

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

Изменения на стороне сервиса

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

Превышение лимитов

У большинства API есть ограничения на количество запросов в секунду или в сутки. Если при выгрузке 10 000 товаров сайт отправляет по запросу на каждую позицию, он упрётся в лимит. Нужны пакетные запросы, кеширование и разумное расписание обмена.

Готовый модуль или собственная разработка

Для популярных связок существуют готовые модули: обмен WooCommerce с МойСклад, интеграции платёжных сервисов с Битриксом, модули служб доставки для разных CMS. Они дешевле и быстрее в подключении, но работают по универсальной логике. Если ваш процесс отличается от типового — например, заказ должен разделяться на несколько отправлений с разных складов или сделка в CRM должна создаваться в определённой воронке в зависимости от суммы, — модуль придётся дорабатывать или заменять.

Наш подход: если готовый модуль закрывает 80–90% задачи и поддерживается автором, берём его и аккуратно дорабатываем. Если процесс нестандартный или модуль заброшен, пишем интеграцию сами. Стоимость отдельной интеграции с 1С или CRM у нас начинается от 40 000 ₽, подробности — на странице услуги интеграции с 1С и CRM.

Как подготовиться к интеграции

Самая важная часть работы происходит до написания кода. Нужно описать процесс так, как он работает в компании на самом деле: кто и когда создаёт товар, где хранятся цены для разных клиентов, когда резервируется товар, кто меняет статус заказа и что происходит при отмене. Часто именно на этом этапе выясняется, что разные отделы понимают процесс по-разному, и интеграция становится поводом навести порядок.

• Определите систему-источник для каждого типа данных: товары, цены, остатки, клиенты, заказы
• Опишите статусы заказа и кто их меняет в какой системе
• Убедитесь, что у товаров есть неизменяемые идентификаторы
• Получите доступы к API всех сервисов на компанию, а не на сотрудника
• Выберите частоту обмена для каждого типа данных
• Назначьте ответственного, который будет получать уведомления о сбоях
• Предусмотрите тестовую среду, чтобы не создавать фиктивные заказы в рабочих системах

Отдельно стоит продумать, что делать при конфликте данных. Например, цена изменилась в 1С в тот момент, когда покупатель уже оформлял заказ. Или менеджер поменял адрес доставки в CRM, а заказ уже передан в службу доставки. Правила разрешения таких ситуаций нужно согласовать заранее, иначе их будет решать код «как получится».

Безопасность обмена

Через интеграции проходят персональные данные покупателей, суммы заказов и коммерческая информация, поэтому к ним применяются те же требования, что и к самому сайту. Ключи доступа к API хранятся в защищённой конфигурации сервера, а не в коде шаблонов и не в переписке. Вебхуки от внешних сервисов проверяются по подписи, чтобы злоумышленник не смог отправить сайту поддельное уведомление «заказ оплачен». Каждой интеграции выдаются только те права, которые ей нужны: модулю доставки незачем иметь доступ к финансовым отчётам в CRM.

Поддержка интеграций после запуска

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

Итоги

Интеграции через API связывают сайт с CRM, учётной системой, службами доставки и платёжными сервисами и избавляют команду от ручного переноса данных. Хорошо сделанная интеграция незаметна: заказы, остатки и статусы просто оказываются там, где нужно, а сбои автоматически ловятся и исправляются.

Ключ к надёжной интеграции — в подготовке и архитектуре: понятные системы-источники для каждого типа данных, неизменяемые идентификаторы, очереди с повторными попытками, журнал обмена и мониторинг. Готовые модули подходят для типовых процессов, собственная разработка — для нестандартных. В обоих случаях интеграция окупается за счёт сэкономленного времени сотрудников и сокращения ошибок, которые стоят денег и репутации.