Слово «API» звучит технически, но за ним стоит простая вещь: две программы умеют обмениваться данными без участия человека. Для владельца сайта это не про технологию, а про то, кто и сколько раз в день переносит цифры из одного окна в другое. Ниже — что интеграции дают на практике, как понять, что вам нужна именно интеграция, и о чём стоит договориться с подрядчиком до начала работ.
Что такое API на языке бизнеса
API — это описанный набор правил, по которым одна система задаёт вопрос другой и получает ответ в предсказуемом формате. Учётная программа не открывает сайту свою базу целиком: она отвечает на конкретные запросы — какой остаток по этому товару, прими новый заказ, какой статус у платежа. Данные идут по тем же каналам, что и обычные страницы, только вместо разметки передаётся структурированный набор полей.
Для владельца сайта важны три следствия. Обмен воспроизводим: одна и та же операция даёт один и тот же результат, а не зависит от того, кто и как её выполнил. Обмен фиксируется: у каждой передачи есть время, состав и итог, поэтому спорную ситуацию можно разобрать по журналу. И обмен ограничен: систему нельзя попросить о том, чего нет в её интерфейсе. Если нужного метода не существует, задача решается обходным путём, и это отдельная работа со своей стоимостью.
Где интеграция окупается
Смысл появляется там, где данные сегодня переносит сотрудник. Мы обычно начинаем разговор с простого перечня: кто, что и как часто копирует. Дальше по этому списку становится видно, какие связки дадут эффект сразу, а какие можно отложить.
| Связка | Что происходит без участия человека | Что перестаёт ломаться |
|---|---|---|
| Сайт и учётная система | Цены и остатки обновляются сами, заказы попадают в учёт | Продажа того, чего нет на складе, и расхождение цен |
| Сайт и CRM | Заявка сразу становится сделкой с источником и историей | Потерянные обращения из почты и форм |
| Сайт и служба доставки | Расчёт стоимости при оформлении, трек-номер в заказе | Ручной пересчёт доставки и звонки «где посылка» |
| Сайт и платёжный сервис | Статус оплаты меняется автоматически, чек уходит покупателю | Отгрузка неоплаченного заказа и сверка вручную |
| Сайт и почта или мессенджер | Уведомление ответственному в момент события | Заявка, которую увидели через сутки |
| Сайт и отчётность | Данные собираются в одном месте по расписанию | Сведение таблиц из нескольких выгрузок |
Как понять, что интеграция нужна вам
Признаки почти всегда бытовые, их видно без аудита:
- сотрудник регулярно копирует данные из одной системы в другую;
- цены и остатки на сайте отличаются от того, что в учёте;
- заявки живут в трёх местах: почта, чат и таблица, и ни одно не полное;
- отчёт за месяц собирается руками из нескольких выгрузок;
- на вопрос «в каком статусе заказ» отвечает человек, а не сайт.
Каждый такой случай считается в часах: сколько минут занимает операция, сколько раз в день она повторяется, кто её делает. Эта арифметика полезнее любых рассуждений об автоматизации — она сразу показывает, какая связка окупится первой, а какая подождёт.
Режимы обмена: сразу или по расписанию
Обмен по событию
Произошло действие — данные ушли немедленно. Так передают заказы, статусы оплаты, изменения статуса доставки. Плюс очевиден: информация актуальна. Минус в том, что принимающая сторона может быть недоступна, поэтому нужна очередь и повторные попытки, иначе одно неудачное соединение теряет заказ навсегда.
Обмен по расписанию
Раз в час или ночью система забирает и отдаёт данные пачкой. Так удобно передавать каталог, цены, остатки, накопленную статистику. Нагрузка предсказуема, разбираться проще, но данные всегда немного отстают, и это нужно проговорить заранее: если остаток обновляется раз в сутки, магазин будет иногда продавать отсутствующий товар.
Кто кого вызывает
Сайт может сам ходить за данными, а может ждать, пока внешняя система постучится к нему. Второй вариант быстрее, но требует, чтобы у сайта был защищённый адрес для приёма и проверка подлинности запроса. Мы всегда уточняем этот пункт: незакрытая точка приёма — это способ создать заказ или изменить статус в обход магазина.
Что спросить у подрядчика до начала работ
- Есть ли у нужного сервиса открытый интерфейс и актуальная документация, или обмен придётся строить на выгрузках файлов.
- Что происходит, когда сервис недоступен: покажем ли мы посетителю понятное сообщение, встанет ли заказ в очередь, будет ли повтор.
- Как часто обмениваются данные и по какому из режимов выше.
- Где хранятся ключи доступа, кто ими управляет и как их поменять без правки кода.
- Как мы узнаем, что обмен сломался, — есть ли уведомление ответственному, а не только запись в журнале.
- Что считается ошибкой обмена и кто её разбирает в рабочем порядке.
Ответы на эти вопросы стоит получить письменно. Они же становятся содержанием приёмки: интеграция считается сделанной не тогда, когда данные один раз прошли, а когда описано поведение в нештатных ситуациях.
Крайние случаи, на которые уходит основное время
Подключение как таковое обычно занимает малую часть работы. Основное время съедает то, что не укладывается в схему «заказ создан — заказ передан»:
- частичная отмена: из заказа на пять позиций убрали одну, нужно пересчитать сумму, скидку и доставку;
- возврат уже оплаченного заказа и корректировка документов;
- товары с вариантами: размеры и цвета в учёте и на сайте описаны по-разному;
- повторная отправка: сервис не ответил вовремя, данные ушли дважды, нужна защита от дублей;
- изменение цены между добавлением в корзину и оплатой;
- ограничение на число запросов в минуту у внешнего сервиса;
- несовпадение справочников: единицы измерения, регионы доставки, ставки налога.
Простая односторонняя выгрузка каталога — работа на несколько дней. Двусторонний обмен со статусами, остатками и возвратами — недели, и почти всё это время уходит на перечисленные выше ситуации, а не на «подключить».
По API чаще всего забирают именно остатки и цены. Если источника нет, забирать неоткуда — и API не спасёт. В оптовых компаниях таким источником становится ERP для оптовой торговли: она ведёт номенклатуру, резервы и отгрузки, а сайт только читает готовые данные.
Что должно остаться у вас после работ
- описание обмена: какие данные передаются, в какую сторону, с какой частотой;
- журнал операций, доступный без разработчика;
- ключи доступа, оформленные на вашу компанию, а не на исполнителя;
- тестовый контур или способ проверить обмен, не трогая боевые заказы;
- инструкция для менеджера: что делать, когда обмен встал.
Без этого разбор одного спорного заказа превращается в переписку на неделю, а смена подрядчика — в разработку интеграции заново. Мы относимся к документации обмена как к части результата, а не как к приложению к нему.
Если данные между сайтом, учётом и CRM у вас до сих пор переносят руками, начните с описания этих операций — дальше видно, что автоматизировать первым. Мы занимаемся такими задачами: разработка информационных систем и интеграций.
