Подключение сервисов по api обычно всплывает в проекте, когда бизнес устал вручную переносить данные: менеджер каждый день выгружает заказы из Tilda в Excel и вбивает их в CRM, бухгалтер сверяет платежи из эквайринга со списком клиентов, курьер вручную переносит адрес доставки в личный кабинет СДЭК. На практике такая связка двух систем занимает от пары дней до нескольких недель работы, и решает её не абстрактная «автоматизация», а конкретный протокол обмена данными между сервисами: кто кому и в какой момент отправляет запрос, как проверяется подлинность отправителя и что происходит, если запрос не дошёл с первого раза.
Зачем связывать сервисы через API
Ручной перенос данных ломается на объёме. Пока в CRM попадает 5-10 заявок в день, менеджер справляется руками и почти не ошибается. Когда заявок становится 50-100, начинаются задвоенные лиды, забытые заказы и разъехавшиеся статусы оплаты. Я считаю так: если на перенос одной записи уходит 2-3 минуты, а записей 80 в день, это 3-4 часа рабочего времени ежедневно, которые можно освободить одной интеграцией.
Второй эффект от подключения сервисов по api - скорость реакции. Когда T‑Bank присылает уведомление об оплате напрямую в WooCommerce, статус заказа меняется за секунды, а не после того, как бухгалтер откроет выписку вечером. Клиент видит подтверждение сразу, склад видит заказ в очереди на сборку сразу, курьерская служба получает данные для расчёта доставки без задержки.
Webhook или polling: как выбрать способ обмена данными
Есть два базовых сценария получения данных от внешнего сервиса.
Webhook - сервис сам присылает запрос на ваш адрес в момент события. Tilda отправляет вебхук при новой заявке, T‑Bank - при изменении статуса платежа. Это быстрый и дешёвый по нагрузке способ: ничего не опрашивается впустую, данные приходят ровно тогда, когда что-то произошло. Условие одно: у вас должен быть публичный HTTPS-адрес, который готов принять запрос и быстро ответить кодом 200, иначе сервис-отправитель посчитает доставку неуспешной и начнёт повторять попытки.
Polling - вы сами с заданным интервалом запрашиваете у сервиса, не изменилось ли что-то. Такой подход нужен, когда сервис не поддерживает вебхуки или отдаёт события с задержкой. У СДЭК, например, часть статусов трекинга удобнее забирать периодическим запросом раз в 15-30 минут, а не ждать колбэка.
- Если сервис поддерживает вебхуки и нужна реакция в реальном времени - берите webhook.
- Если нужна история изменений за период или сервис вебхуки не отдаёт - берите polling с разумным интервалом.
- Если событие критичное (оплата, отмена заказа) - дублируйте вебхук периодической сверкой раз в сутки, чтобы поймать случаи, когда колбэк не дошёл.
Аутентификация и защита канала между сервисами
Каждый обмен данными между сервисами держится на трёх вещах: ключе доступа, проверке подписи и логах.
Ключ доступа (API key или токен OAuth2) хранится в переменных окружения на сервере, а не в коде скрипта и точно не в клиентской части сайта. Кастомный скрипт для Tilda выполняется в браузере посетителя, и если зашить туда секретный токен CRM, его увидит любой, кто откроет консоль разработчика. Такие интеграции я всегда развожу через промежуточный серверный обработчик: браузер стучится на свой эндпоинт, а он уже с секретным ключом обращается к CRM или платёжной системе.
Проверка подписи нужна, чтобы отличить настоящий вебхук от подделанного запроса на тот же адрес. T‑Bank подписывает уведомление токеном терминала, и на своей стороне я пересчитываю подпись и сверяю её до того, как менять статус заказа в базе. Без этой проверки любой, кто узнает адрес вебхука, теоретически может отправить туда фиктивное «оплата прошла».
Логи обязательны с первого дня: что пришло, с каким статусом ответили, сколько раз повторили попытку. Без логов диагностика сбоя занимает часы вместо минут, а разбираться приходится по памяти вместо конкретных данных запроса.
Отдельно про персональные данные: если через интеграцию идут контакты клиентов (телефон, email, адрес), храните их на серверах в России, а не в иностранных облачных таблицах - это требование 152-ФЗ о локализации персональных данных, и на него стоит закладываться ещё на этапе выбора инструмента для синхронизации.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
n8n или кастомный скрипт: что использовать для синхронизации
Для типовых сценариев (Tilda в Bitrix, Google Таблицы в Telegram, новая заявка в чат-бота на aiogram) я обычно беру n8n - там уже есть готовые узлы для десятков сервисов, и связка собирается за 1-3 дня без написания бэкенда с нуля. Для сложной логики с очередями, повторными попытками при сбое стороннего API и разветвлённой обработкой ошибок нужен кастомный сервис, потому что визуальный редактор на таком объёме условий становится сложнее читать, чем код.
| Способ подключения | Срок реализации | Когда используется |
|---|---|---|
| Готовый сценарий в n8n | 1-3 дня | Типовые связки: CRM, таблицы, уведомления в Telegram |
| Кастомный скрипт для Tilda + вебхук | 2-5 дней | Приём оплаты, заявок, статусов доставки на конкретной странице |
| Отдельный бэкенд-сервис | от 2 недель | Несколько систем сразу, очереди, повторные попытки, сложная бизнес-логика |
По деньгам ориентир такой: простая доработка скрипта под один вебхук у меня стоит от 3 000 ₽, комплексная интеграция с CRM, эквайрингом и СДЭК одновременно - от 40 000 ₽, автоматизация в n8n - от 25 000 ₽, а отдельный бэкенд-сервис на Laravel под несколько систем - от 100 000 ₽. У других разработчиков и в студиях цены на похожие задачи на рынке обычно выше за счёт менеджмента проекта и более длинного согласования ТЗ.
Если сценарий выходит за рамки одного триггера и нужна связка с очередями, повторными попытками и логированием ошибок, я беру такие задачи в разработку интеграции по api под ключ - на входе смотрю API обеих систем и уже от этого считаю смету и срок.
Примеры из практики: T‑Bank, СДЭК, Telegram-бот
T‑Bank и WooCommerce: эквайринг присылает вебхук об оплате, обработчик на сервере проверяет подпись, меняет статус заказа и запускает отправку письма клиенту. Без интеграции статус приходится сверять руками по личному кабинету банка раз в день, и заказ висит в ожидании до следующей проверки.
СДЭК: расчёт стоимости и сроков доставки запрашивается через API прямо в корзине, чтобы клиент видел цену до оформления заказа, а не после звонка менеджера. Статусы посылки после отправки забираю периодическим запросом, потому что часть событий трекинга приходит с задержкой относительно реального перемещения груза.
Telegram-бот на aiogram: вебхук от Tilda при новой заявке уходит на сервер, тот формирует сообщение и отправляет его в бота менеджеру с кнопками «взять в работу» и «отклонить». Ответ менеджера через бота обратным запросом меняет статус заявки в CRM без единой ручной строки в таблице.
Типичные ошибки при подключении сервисов по API
- Нет проверки на повторную доставку. Сервис может прислать один и тот же вебхук дважды при сетевом сбое, и без проверки на дубликат заказ создаётся два раза.
- Секретный токен зашит в клиентский скрипт Tilda вместо серверного обработчика.
- Нет логов - при сбое непонятно, дошёл ли запрос вообще и что ответил сервер.
- Игнорируются лимиты запросов (rate limit): при превышении частоты обращений сервис временно блокирует ключ, и вся интеграция встаёт.
- Нет обработки таймаута. Если СДЭК или платёжная система не ответили за разумное время, скрипт должен повторить запрос с паузой, а не зависнуть или молча потерять данные.
Частые вопросы
Сколько стоит подключить два сервиса по API?
Простая доработка вроде одного вебхука на Tilda стоит от 3 000 ₽. Комплексная интеграция с CRM, эквайрингом и доставкой одновременно - от 40 000 ₽. Автоматизация типового сценария в n8n - от 25 000 ₽. Точная сумма зависит от того, сколько систем участвует и нужна ли обработка повторных попыток и очередей.
Что делать, если у сервиса нет готового API?
Проверьте документацию на наличие партнёрского или закрытого API - у многих сервисов он есть, но не рекламируется на главной странице. Если API действительно нет, остаются экспорт по расписанию (CSV, выгрузка в таблицу) или, для некоторых платформ, отправка данных через встроенные вебхуки форм.
Чем webhook отличается от периодического опроса (polling)?
Вебхук - это сервис сам присылает запрос вам в момент события, без задержки и без лишней нагрузки на оба сервера. Polling - вы сами с заданным интервалом спрашиваете сервис, не изменилось ли что-то, и это уместно только там, где вебхуков нет или события не критичны по времени.
Как проверить, что интеграция работает без сбоев?
Веду логи каждого запроса и ответа минимум 30 дней, ставлю уведомление в Telegram на код ответа отличный от 200 и раз в неделю сверяю количество событий в источнике и в целевой системе вручную на выборке в 10-20 записей.