Когда в бизнесе работает больше нескольких онлайн-инструментов, кто-нибудь спрашивает, почему каждый заказ из магазина приходится вручную вводить в бухгалтерскую систему. Связать их можно двумя способами: платформой интеграции с готовыми коннекторами или API-интеграцией на заказ, написанной под ваши системы. Работают оба. Правильный выбор зависит от объёма, от того, сколько всего может пойти не так, и от того, кто будет присматривать за соединением через год.

В чём сильны no-code платформы интеграции

Платформы вроде Zapier, Make и n8n предлагают no-code интеграцию: выберите триггер в одном приложении и действие в другом, затем сопоставьте поля между ними. Для многих небольших задач это правильный ответ:

  • Малый объём, например несколько десятков новых лидов в день, копируемых в CRM.
  • Односторонние потоки с простым сопоставлением: отправка формы становится задачей, оплаченный счёт отправляет сообщение команде.
  • Приложения с хорошо поддерживаемыми коннекторами на платформе.
  • Процессы, которые сотрудник компании может изменить без разработчика.

По сути, такие платформы — это ПО для API-интеграции, продаваемое по подписке, и они быстрее всего показывают, нужна ли автоматизация вообще.

Где no-code начинает не справляться

  • Оплата за задачи. Большинство платформ берёт плату за число задач или операций. Процесс, который запускается для каждой строки заказа или каждого изменения остатка, по мере роста бизнеса может стать дорогим.
  • Лимиты запросов. API ограничивают, сколько запросов может отправить клиент, часто отвечая статусом HTTP 429, Too Many Requests, определённым в RFC 6585. Напряжённый день может упереть процесс в эти лимиты, а не каждый коннектор разумно ждёт и повторяет запрос.
  • Двусторонняя синхронизация. Чтобы клиенты или остатки были одинаковыми в двух системах, нужно решить, какая из них главнее, когда меняются обе. Коннекторы, построенные на односторонних триггерах, справляются с этим плохо.
  • Обработка ошибок. Неудачный шаг может отображаться только в истории платформы и больше нигде, так что пропавший счёт замечают в конце месяца.
  • Недостающие поля. Готовые коннекторы открывают распространённые поля; налоговые коды, пользовательские атрибуты или данные на уровне строк могут быть недоступны.
  • Разрастание. Тридцать небольших процессов, созданных разными людьми за два года без документации, сами становятся недокументированной системой.

Когда API-интеграция на заказ оправдана

Работа на заказ имеет смысл, когда соединение — часть работы бизнеса, а не удобство:

  • Объём велик или растёт, и оплата за каждую задачу уже не сходится.
  • Данные должны быть согласованы в обоих направлениях, с чёткой основной системой учёта для клиентов, товаров, цен и остатков.
  • У программы есть API, но нет готового коннектора, либо в коннекторе нет нужных вам полей.
  • Сбои имеют последствия: неотправленные заказы, невыставленные счета, перепроданные остатки.
  • Вам нужны журналы, оповещения и повторные попытки, которые можно проверить, с учётными данными в ваших собственных аккаунтах.

Разработка и интеграция API такого рода — небольшой программный проект. Нужны сопоставление полей, тестирование на тестовых аккаунтах и мониторинг после запуска; именно так организована наша работа по API-интеграции. Некоторые поставщики называют это услугами API-подключения или промежуточным ПО; название важно меньше, чем журналирование и оповещения. Большая часть заказов на разработку API, которые поступают от компаний Лос-Анджелеса, вовсе не новый публичный API, а надёжное соединение между магазином, CRM, бухгалтерским пакетом и службой доставки. О тарифах перевозчиков, этикетках и отслеживании см. отдельно интеграцию API доставки.

Часто ответ — гибрид

Выбор редко бывает «всё или ничего». Распространённая схема: код на заказ для основных потоков, таких как заказы, счета и остатки, а no-code платформа остаётся для небольших уведомлений и разовых задач, которые сотрудники любят подстраивать сами. Некоторые платформы можно также развернуть у себя, что оставляет данные и учётные данные на вашем собственном сервере. Важно, чтобы кто-то знал, где живёт каждое соединение, какой аккаунт оно использует и кого уведомляют о сбое.

Вопросы, которые стоит решить до выбора

Нанимаете ли вы услуги API-интеграции или делаете всё своими силами, сначала ответьте на эти вопросы:

  1. Сколько записей передаётся в день и сколько в самый загруженный час?
  2. Данные идут в одну сторону или обе системы должны оставаться согласованными?
  3. Какая система является основной записью для каждого типа данных?
  4. Что произойдёт, если соединение пропадёт на час, день или неделю?
  5. Кто будет его поддерживать и кто получает оповещение при сбое?
  6. Где хранятся ключи API и разрешения OAuth? Они должны создаваться в ваших собственных аккаунтах, а не в аккаунтах подрядчика.

Часто задаваемые вопросы: API-интеграция на заказ

Можно ли позже заменить no-code процесс кодом на заказ?

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

Безопаснее ли интеграция на заказ, чем no-code платформа?

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

Что должна записывать интеграция в журнал?

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

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