Что такое API простыми словами: как сайты обмениваются данными

За год работы беру в среднем десяток интеграций между сайтами и сторонними сервисами: виджет СДЭК на Tilda, прием оплаты через T‑Bank на WooCommerce, telegram-бота на aiogram, который тянет данные из CRM. На созвоне с клиентом почти всегда всплывает вопрос, что такое API простыми словами, хотя человек пользуется им каждый день через банковское приложение, службу доставки или карты в браузере. API - это набор правил, по которым один сервис по заранее оговоренному контракту запрашивает данные у другого сервиса или передает ему данные, не заглядывая в его код и базу.

Что такое API простыми словами на примере из практики

Расшифровка звучит как «программный интерфейс приложения», но понятнее это объяснить через конкретный случай. Ставлю на сайт клиента виджет расчета доставки СДЭК: покупатель вводит город, и через секунду видит стоимость и сроки. Браузер сам не считает тарифы, у него нет доступа к базе СДЭК и к договорным условиям продавца. Вместо этого скрипт на странице отправляет запрос на мой сервер, сервер обращается к API СДЭК, получает готовый ответ и отдает его странице в нужном виде.

API работает как список правил игры между двумя программами: какие данные отправить, в каком формате, по какому адресу и что придет в ответ. Схема одинаковая что для расчета доставки, что для приема оплаты через эквайринг, что для отправки сообщения в Telegram.

Из чего состоит запрос к API: эндпоинты, методы и JSON

Любой запрос складывается из нескольких частей. Эндпоинт - это адрес, по которому сервис принимает обращения, например https://api.cdek.ru/v2/calculator/tariff. Метод указывает, что нужно сделать с этим адресом.

Запрос обычно сопровождают заголовки: Content-Type сообщает, что тело запроса в формате JSON, Authorization передает ключ доступа. Выглядит это так:

curl -X POST "https://api.cdek.ru/v2/calculator/tariff" 
  -H "Authorization: Bearer ВАШ_ТОКЕН" 
  -H "Content-Type: application/json" 
  -d '{"tariff_code": 136, "from_location": {"code": 44}, "to_location": {"code": 270}, "packages": [{"weight": 1000}]}'

У расчёта тарифа СДЭК метод только POST с телом запроса - GET здесь вернёт ошибку 405, для операций без изменений (например для списка пунктов выдачи) метод остаётся GET.

В ответ сервис возвращает код статуса и тело в JSON. 200 значит запрос прошел, 400 обычно говорит о том, что не хватает обязательного поля, 401 о неверном ключе, 404 о несуществующем адресе, 429 о превышении лимита запросов, 500 об ошибке на стороне самого сервиса.

{
  "delivery_sum": 350,
  "period_min": 2,
  "period_max": 4
}

REST, вебхуки и другие способы обмена данными между сервисами

Большинство API, с которыми я работаю, построены по принципу REST: у каждого ресурса свой адрес, а действия с ним описываются стандартными HTTP-методами из таблицы выше. Это удобный и предсказуемый стиль, поэтому он стал стандартом де-факто для СДЭК, T‑Bank и почти всех CRM.

Есть и обратная схема - вебхук. Здесь не я обращаюсь к сервису, а сервис сам присылает POST-запрос на мой адрес при наступлении события. T‑Bank, например, шлет вебхук с итоговым статусом платежа, как только покупатель оплатил заказ на форме эквайринга. Это дешевле по нагрузке, чем опрашивать сервис каждые несколько секунд в цикле, и почти всегда быстрее по времени реакции.

Собирать несколько таких обменов в один сценарий удобно в n8n: вебхук от Tilda прилетает в воркфлоу, дальше нода проверяет данные заказа и отправляет уведомление менеджеру в Telegram или создает задачу в CRM. Код почти не нужен, узлы просто соединяют разные API между собой.

Ключи и токены: как API проверяет, кто обращается к серверу

Чтобы сервис не отвечал первому встречному, запросы подписывают ключом или токеном. Простой вариант - API-ключ в заголовке Authorization, более гибкий - OAuth-токен с ограниченным сроком жизни и набором прав.

Здесь есть частая ловушка именно на Tilda: если вписать секретный ключ прямо в zero-block скрипт, он окажется виден любому через просмотр исходного кода страницы. Ключ от эквайринга или от CRM в браузере светить нельзя, поэтому запрос уходит сначала на свой сервер, а уже он с ключом на борту стучится к нужному API. Обычно для такой схемы я делаю отдельный серверный бэкенд под интеграцию, который прячет ключ, логирует ошибки и переживает смену токена без правки скрипта на сайте.

Сервисы вроде СДЭК и T‑Bank также ограничивают число запросов в единицу времени. При превышении лимита приходит статус 429, и повторные попытки нужно делать с паузой, а не долбить API в цикле без задержки.

Примеры API в реальных интеграциях: СДЭК, T‑Bank, Tilda и n8n

• СДЭК: расчет стоимости и сроков доставки, получение списка пунктов выдачи, создание заказа и отслеживание трек-номера. Интеграцию такого виджета в Tilda я обычно закрываю за 3-5 дней.
• T‑Bank: создание платежа и редирект покупателя на форму оплаты, затем вебхук с итоговым статусом. Важный нюанс на практике - суммы передаются в копейках, а не в рублях, и это первое, что ломается при переносе кода с другого проекта.
• Tilda: собственный API есть, на api.tildacdn.info, но доступен он только на тарифе Business, ограничен лимитом 150 запросов в час и работает исключительно на чтение - отдает список проектов, список страниц и их html-код. Записать через него данные в сайт нельзя, поэтому рабочая логика живет в zero-block скриптах, которые через fetch дергают внешние сервисы, и вся история с ключами и обработкой ошибок ложится на прокси-сервер.
• aiogram-бот: работает через Telegram Bot API, либо через long polling с постоянным опросом сервера, либо через вебхук, который отдает сообщения сразу при поступлении.
• n8n: no-code оркестрация нескольких API одним сценарием без бэкенда под каждую связку сервисов.

Частые ошибки при подключении к чужому API

• Секретный ключ в клиентском JavaScript вместо серверного прокси.
• Запросы без учета лимита - сервис начинает отвечать 429 или временно блокирует IP.
• Обязательные поля запроса не сверены с документацией, из-за чего постоянно прилетает 400.
• Суммы и единицы измерения не приведены к формату сервиса, как в примере с копейками у T‑Bank.
• Повторные вебхуки от одного события обрабатываются как новые, и заказ задваивается в базе.
• Ответы сервиса нигде не логируются, поэтому разбор сбоя занимает часы вместо минут.

Подключение стороннего API к сайту у меня как разработчика начинается от 40 000 ₽ за комплексную интеграцию вроде CRM, эквайринга или СДЭК на готовой платформе, а отдельный бэкенд под API уровня Laravel - от 100 000 ₽. У других разработчиков и в студиях на рынке ценник за похожую задачу обычно колеблется от 30 000 до 150 000 ₽ в зависимости от того, насколько внятная документация у сервиса и сколько там нестандартных полей.

Частые вопросы

Чем API отличается от SDK

API - это контракт запросов и ответов, описанный в документации сервиса. SDK - готовый набор кода на конкретном языке программирования, который эти запросы уже оборачивает в удобные функции. SDK строится поверх API, а не заменяет его.

Нужно ли знать программирование, чтобы работать с API

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

Сколько стоит подключить API к сайту

Комплексная интеграция стороннего сервиса вроде СДЭК, T‑Bank или CRM в Tilda у меня начинается от 40 000 ₽, отдельный бэкенд под API уровня Laravel - от 100 000 ₽. На рынке у других разработчиков цена за похожую задачу обычно от 30 000 до 150 000 ₽ в зависимости от сложности документации сервиса.

Чем REST API отличается от обычного API

API - общее понятие любого программного интерфейса для обмена данными между программами. REST - конкретный архитектурный стиль построения такого интерфейса поверх HTTP, где у каждого ресурса свой адрес и стандартный набор методов. Кроме REST встречаются SOAP, GraphQL и gRPC, но на практике в связке с Tilda, СДЭК и T‑Bank чаще всего работаешь именно с REST.