Приложение на основе API сайта - это когда у вас уже есть сайт с данными: каталог, заказы, склад, личные кабинеты, и вместо повторного ввода той же информации вы строите отдельный продукт, который читает и пишет через тот же API. Это может быть Telegram-бот, мобильное приложение, внутренняя CRM-панель или отдельный SaaS-сервис для клиентов. За последние пару лет я делал такие проекты и поверх Tilda с кастомным бэкендом, и поверх WooCommerce, и с нуля на Laravel, и в каждом случае первые вопросы одинаковые: что реально отдаёт API, какие лимиты у запросов и вебхуков, и как не переписывать интеграцию через три месяца, когда на сайте поменяют структуру данных.
По теме статьи
Готовое решение
AI-чатбот для сайта на Claude - отвечает как ваш менеджер, работает 24/7
Подключу к вашему сайту чат-бота на Claude API. Бот отвечает на вопросы клиентов голосом вашего бренда, знает каталог и условия доставки, забирает лиды в CRM или Telegram.
от25 000 ₽
SaaS / SPA
Когда нужен не сайт, а сервис
SaaS, личный кабинет, CRM, внутренний инструмент. Next.js, React, Vue.js, Laravel, Python — подберу стек под задачу. MVP за 4-8 недель.
от300 000 ₽
Когда нужно приложение на основе API сайта, а когда хватит доработки
Не каждая задача требует отдельного приложения. Если нужно поменять текст на странице, добавить форму или посчитать скидку по промокоду - это доработка самого сайта, и на Tilda такие вещи закрываются кастомным скриптом за пару дней. Отдельное приложение имеет смысл, когда данные с сайта нужны в другом месте и в другом виде: менеджеру в Telegram, кладовщику в мобильном приложении, бухгалтеру в отчёте, который сайт сам никогда не покажет.
Пример из практики: у клиента интернет-магазин на WooCommerce, и менеджеры весь день сидели в админке WordPress, чтобы посмотреть новые заказы и проставить статус доставки. Мы собрали Telegram-бота на aiogram, который читает заказы через WooCommerce REST API и присылает уведомление в чат сразу после оплаты через T‑Bank. Админка осталась для бухгалтерии, а рутинная работа менеджеров переехала туда, где они и так сидят весь день.
Другой пример - интернет-магазин с доставкой через СДЭК, где вручную считали стоимость и сроки в личном кабинете транспортной компании, а потом переносили цифры в заказ на сайте. Отдельное приложение забирает эти расчёты через API СДЭК и подставляет их клиенту сразу на странице оформления, без ручного пересчёта.
Что проверить в API сайта до начала разработки
Прежде чем писать код, я смотрю на четыре вещи.
- Тип API. REST встречается чаще всего, у WooCommerce и большинства CMS он готовый из коробки. Иногда сайт отдаёт данные только через вебхуки, без возможности запросить их по требованию, и тогда приложение приходится строить вокруг событий, а не вокруг запросов.
- Авторизация. У WooCommerce это consumer key и consumer secret, у T‑Bank для эквайринга - токен терминала и подпись запроса по алгоритму из документации, у Tilda - персональный API-ключ проекта. Формат разный, но логика одна: ключи хранятся на сервере приложения, а не в коде клиента, иначе их вытащат из исходников за пять минут.
- Лимиты запросов. Rate limit есть почти у всех API, и если приложение дёргает его на каждое действие пользователя, довольно быстро упрётесь в ответ с кодом 429. Решается кэшем и очередью задач, но закладывать архитектуру под это нужно сразу, а не после первого падения бота в проде.
- Что можно писать, а что только читать. Часть API отдаёт данные только на чтение: каталог, остатки, статистику. Изменение статуса заказа или списание товара идёт через отдельные, более закрытые эндпоинты либо вообще недоступно - тогда приложение работает в связке с админкой сайта, а не вместо неё.
Отдельно смотрю на документацию и версионирование: если у API нет описания эндпоинтов, а есть только «спросите у бэкенд-разработчика в чате», закладываю время на то, чтобы вытащить всё самому через DevTools и тестовые запросы. А если версия API у сайта уже вторая или третья, уточняю, когда закроют предыдущую - иначе приложение может сломаться в день, когда старую версию отключат без предупреждения.
Так выглядит обычный запрос списка заказов в статусе «в обработке» через WooCommerce REST API - ключи консьюмера передаются базовой авторизацией, а не в адресной строке:
curl -X GET "https://shop.example.com/wp-json/wc/v3/orders?status=processing" \
-u ck_71a9...:cs_44f2...Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Архитектура: как клиентское приложение обменивается данными с API сайта
Работают два подхода, и обычно их совмещают.
Первый - синхронные запросы: приложение спрашивает API сайта каждый раз, когда пользователю нужны свежие данные. Годится для панелей администратора и CRM, где важна актуальность, а нагрузка невысокая.
Второй - события через вебхуки: сайт сам присылает уведомление, когда что-то произошло, а приложение только реагирует. Так устроена доставка статусов у СДЭК - трекер шлёт вебхук об изменении статуса посылки, и опрашивать их API в цикле, проверяя, не изменилось ли что-то, не нужно и не имеет смысла.
На практике чаще всего использую оба варианта плюс промежуточное хранилище: каталог товаров с сайта раз в час синхронизируется в собственную базу приложения по расписанию, а заказы и оплаты приходят вебхуками в реальном времени. Это снимает нагрузку с API сайта и защищает приложение от того, что при недоступности сайта встанет всё остальное.
Логирование ошибок подключаю сразу, а не когда что-то отвалилось: если API сайта вернул 500‑ю ошибку или изменил формат ответа, хочу узнать об этом из уведомления, а не от клиента, который написал, что бот перестал отвечать.
Стек для разработки приложения на API сайта
Выбор стека зависит от того, что должно получиться на выходе.
Для собственного бэкенда, который проксирует, кэширует и обогащает данные из API сайта, беру Laravel - там из коробки есть очереди, кэш и HTTP-клиент под такие задачи. Для панели администратора или клиентского кабинета поверх этого бэкенда - React.
Если задача - бот для отдела продаж или клиентов в Telegram, использую aiogram на Python: он быстро связывается с любым REST API и не требует отдельного фронтенда, а первую рабочую версию можно показать заказчику за неделю.
Когда логика простая - переложить данные из одной системы в другую, посчитать что-то и отправить уведомление - обхожусь без отдельного бэкенда через n8n: он умеет дёргать HTTP-запросы к API сайта, принимать вебхуки и писать результат в CRM или таблицу. Для интеграции вида «заказ на сайте - уведомление в отдел продаж - запись в CRM» это быстрее и дешевле, чем поднимать сервер с нуля.
Отдельного нативного мобильного приложения на этом стеке обычно не делаю - чаще хватает PWA или Telegram-мини-аппа поверх того же бэкенда, это дешевле и быстрее в поддержке.
Часть готовых решений под Tilda уже собрана заранее - смотрите готовые скрипты, например калькулятор зон доставки и конвертер валют, которые можно взять за основу вместо разработки с нуля.
Практические сценарии: где приложение поверх API сайта окупается быстрее всего
- Приём оплаты и синхронизация заказов: эквайринг T‑Bank на сайте, статус оплаты приходит вебхуком, дальше бот или CRM реагируют без участия человека.
- Доставка: расчёт стоимости и сроков через API СДЭК прямо в приложении заказа, без похода в личный кабинет транспортной компании.
- Внутренние отчёты: дашборд на Vue или React, который раз в сутки забирает данные из API сайта и считает выручку, средний чек, остатки - без ручного экспорта из админки.
- Автоматизация рутины в n8n: сценарий «новый лид с формы на сайте - проверка на дубль в CRM - уведомление в Telegram менеджеру» собирается за пару дней без единой строчки кода бэкенда.
- ИИ поверх данных сайта: чат-бот с базой знаний на Claude API, который отвечает клиентам по каталогу и условиям доставки, а не просто пересказывает FAQ-страницу.
- Мобильное приложение для курьера или кладовщика: список задач на день подтягивается из API сайта, а отметка о выполнении уходит обратно тем же путём, без бумажных накладных.
Сколько стоит и сколько занимает разработка приложения на API сайта
Цена и срок сильно зависят от того, что именно строим поверх API, поэтому сравнивать лендинг и SaaS в одной строке смысла нет - у них разный объём работы, а не разная сложность самого подключения к API.
В оценку закладываю не только код: разведку API, тестовые запросы к рабочим и тестовым окружениям сайта и минимум неделю на проверку под реальными данными после запуска.
| Что делаем | Цена | Срок |
|---|---|---|
| Telegram-бот на aiogram поверх API сайта | от 30 000 ₽ | от 1-2 недель |
| Сценарий автоматизации в n8n | от 25 000 ₽ | от 1 недели |
| Парсинг и автоматизация на Python | от 20 000 ₽ | от 1-2 недель |
| Комплексная интеграция для Tilda (CRM, эквайринг, СДЭК) | от 40 000 ₽ | от 2 недель |
| CRM или админ-панель на React поверх API | от 100 000 ₽ | от 4 недель |
| API-бэкенд на Laravel | от 100 000 ₽ | от 3-4 недель |
| Веб-сервис или SPA поверх API сайта | от 300 000 ₽ | от 8 недель |
| AI-интеграция поверх данных сайта (Claude API, RAG) | от 50 000 ₽ | от 2-3 недель |
Домен и SSL в эти цифры не входят и от типа приложения не зависят: доменная зона .ru стоит иначе, чем .com, а цена сертификата определяется его типом, а не тем, что вы строите. Комиссия эквайринга у T‑Bank и других банков - это тариф самого банка, он одинаковый что для лендинга, что для сложного SaaS.
Частые вопросы
Нужен ли доступ к исходному коду сайта, чтобы разработать приложение на его API?
Нет, если API уже есть и документирован - достаточно ключей доступа и описания эндпоинтов. Доступ к коду нужен только когда API нет вообще и его приходится добавлять на сам сайт.
Что делать, если у сайта нет публичного API?
Смотрю, что предоставляет платформа: у большинства CMS и конструкторов, включая Tilda и WordPress, есть встроенный или официальный API, просто не всегда включённый по умолчанию. Если совсем ничего нет, добавляю минимальный API на сам сайт - отдельные эндпоинты под конкретную задачу, без переписывания всей платформы. На разведку обычно уходит день-два, дальше это закладывается в оценку проекта отдельной строкой.
Сколько стоит поддержка приложения, если API сайта поменяется?
Отдельно, по факту работ - бесплатные доработки на будущее я не закладываю ни в один проект. Техподдержка с реакцией на изменения API оформляется отдельно, от 15 000 ₽ в месяц, и туда входит мониторинг ошибок и правки под новые версии эндпоинтов.
Какой стек выбрать: полноценный бэкенд или n8n без кода?
Если логика укладывается в «получить данные - обработать - отправить» без сложных условий, n8n закрывает это быстрее и дешевле. Как только появляется своя бизнес-логика, хранение данных и права доступа для разных ролей, нужен отдельный бэкенд - тут беру Laravel или Node.js в зависимости от того, что уже есть в проекте.