В прошлом году у нас был проект на Laravel 11. Стартовали с «просто сайта», а через 4 месяца собственник принес новый план: мобильное приложение, amoCRM, Telegram-бот и кабинет партнера. Стало понятно, что дело не в людях и не в темпе команды. Бэкенд хорошо отдавал страницы, но слабо работал как сервис для внешних каналов.
На старте базовый API добавил бы к смете около 10-15%. Когда это решение откладывают, позже почти всегда появляется отдельный этап на 3-6 недель с переделкой авторизации, прав, статусов и структуры данных. Я не раз видел эту развилку: небольшая инвестиция в начале или дорогая реконструкция потом.
Потолок у «просто сайта» приходит быстро
Пока продукт живет в одном интерфейсе, отсутствие API почти незаметно. Сайт работает, заявки идут, менеджер не жалуется. Проблемы начинаются в момент, когда бизнес открывает второй канал: приложение, CRM, бот, платежи, кабинет дилера.
У нас был проект, где часть логики скидок жила во Vue, часть - в админке WordPress, еще кусок - в прямых запросах к PostgreSQL. Клиент попросил Telegram-бота и кабинет для партнеров. Вместо интеграции за несколько дней мы сначала строили API-слой почти 3 недели. Это уже не интеграция, а реконструкция системы.
Мини-диалог там был короткий и очень знакомый:
- У нас же backend уже есть. Почему приложение нельзя просто подключить?
- Потому что у вас backend заточен под страницы, а не под обмен данными.
- То есть приложение уперлось не во фронтенд?
- Оно уперлось в архитектуру.
API - это контракт, который держит систему в сборе
REST API ценен не списком URL и не словами GET/POST/PATCH. Его практическая польза в том, что бизнес-логика живет в одном месте, а сайт, приложение и кабинет используют один и тот же контракт. Когда подрядчик меняется, новой команде не приходится заниматься археологией в шаблонах и SQL-скриптах.
Мы обычно фиксируем контракт через OpenAPI 3.1 и сразу поднимаем Swagger UI. Для бизнеса это тоже полезно: видно, какие данные обещает система, какие ошибки она вернет и где нужна авторизация. Когда такого контракта нет, на этапе интеграции почти неизбежны споры.
| Критерий | Есть API | Нет API |
|---|---|---|
| Запуск нового канала | 1-2 недели | 4-8 недель |
| Стоимость изменений | локальная | цепляет полсистемы |
| Зависимость от подрядчика | ниже | выше |
| Логика скидок и статусов | одна версия правил | несколько версий сразу |
На проекте в оптовой торговле после выноса правил в единый REST API расхождения по ценам и статусам снизились на 34%. Цифры говорят сами за себя: убрали три источника правды, получили меньше ручных разборов и меньше потерь времени у менеджеров.
Деньги дает не API, а сценарии поверх него
Сам API не создает выручку. Выручку дает цепочка, которая работает без ручных пересборок: заказ создан, адрес проверен, маршрут рассчитан, клиент уведомлен, статус дошел до CRM.
Для такой связки мы чаще всего используем готовые внешние сервисы:
- карты и маршруты - API Яндекс Карт
- уведомления - Telegram Bot API и WhatsApp Business Platform
- AI-сценарии - API Yandex GPT
- платежи - готовые платежные шлюзы
Если функция не дает конкурентного преимущества, ей не стоит съедать спринты команды. Свое имеет смысл писать там, где у бизнеса действительно уникальная логика: роли, документы, статусы, согласования, партнерские правила.
Частая ошибка - подключать каждую интеграцию как отдельную фичу: сначала карты, потом бот, потом CRM. Рабочий подход другой: сначала собрать единый сценарий и определить, где будет жить бизнес-логика - в интерфейсах или в API.
На доставке такой подход дал понятный эффект: менеджеры тратили на обработку заказа на 34% меньше времени, а потерянные заявки из-за забытых статусов снизились на 18% за первый месяц.
Самый дорогой API - тот, который решили сделать потом
Полный API «на вырост» с первого дня нужен не всем. Нужен базовый слой, который выдержит рост: авторизация, роли, единые сущности, версия API, журнал действий, запас под новые каналы. Если этого нет, через полгода любая доработка начинает стоить как мини-перезапуск.
Был кейс под NDA в B2B-сервисе для выездных инженеров. Стек - Node.js 20 + NestJS, PostgreSQL 16, Redis 7. Клиент хотел быстро открыть веб-кабинет, а мобильную часть оставить «на потом». Через 5 месяцев понадобились приложение и интеграция с Bitrix24. Из-за того что часть правил сидела в шаблонах интерфейса, мы потратили 7 недель только на перенос логики в API-слой.
У нас был и обратный опыт: мы пробовали делать «временные» endpoint'ы под каждую новую задачу. На коротком отрезке это выглядело дешево, но через полгода сопровождение стало дороже, чем если бы нормальный контракт собрали сразу. Это как раз тот случай, где экономия на старте увеличивает TCO системы уже в первый год.
Как проверить зрелость API до подписания сметы
Я бы просил подрядчика показать не обещания, а контракт и несколько реальных примеров запросов. Хорошая команда быстро отвечает на вопрос, как система переживет второй и третий канал продаж.
Смотреть стоит на четыре вещи:
- авторизация - OAuth 2.0, JWT или API keys, без самодеятельности
- защита от дублей - идемпотентность для заказов, оплат и броней
- ограничения запросов - rate limiting, чтобы интеграция не положила сервис
- аудит - кто и когда создал, изменил или отменил критичную операцию
POST /orders
Idempotency-Key: 8f2c-2026-001
Authorization: Bearer token
{
"client_id": 1542,
"items": [{"sku": "A-17", "qty": 2}]
}
Если после обрыва связи такой запрос создает второй заказ, проблема уже не в интеграции, а в прямых потерях денег на дублях.
Перед стартом проекта я бы задал один вопрос раньше остальных: если через 6-12 месяцев вам понадобятся приложение, кабинет партнера и CRM, ваша система останется продуктом или превратится в набор экранов?
