API

API (Application Programming Interface, программный интерфейс приложения) — набор правил и протоколов, по которым одни программы взаимодействуют с другими: передают команды, запрашивают и получают данные. В маркетинге без API не работает ни одна серьезная интеграция — от выгрузки статистики из рекламных кабинетов до передачи офлайн-конверсий в алгоритмы автоматической оптимизации.

Что такое API

Представьте, что вы приходите в ресторан. Вы не идете на кухню и не говорите повару напрямую — вы делаете заказ через официанта, который знает, что принять, как передать на кухню и что принести обратно. API — это официант между двумя программами. Одна программа (клиент) отправляет запрос по строго определенным правилам: метод, адрес, данные. Другая программа (сервер) принимает запрос, обрабатывает его и возвращает ответ в том же структурированном формате. Яндекс.Директ не дает сторонним программам напрямую работать со своей базой данных — но предоставляет API, через который рекламные инструменты создают кампании, меняют ставки и получают статистику.

Концепция программных интерфейсов появилась в 1950-60-е годы вместе с первыми операционными системами — тогда API означал набор вызовов к ресурсам компьютера. В вебе ситуация изменилась в начале 2000-х: Salesforce в 2000 году и eBay в 2001-м первыми открыли публичные API, позволив сторонним разработчикам работать с их платформами. Twitter открыл API в 2006 году, и за несколько лет вокруг него выросла экосистема из тысяч приложений. Рой Филдинг в диссертации 2000 года описал архитектурный стиль REST, который к 2010-м вытеснил более громоздкий SOAP и стал стандартом де-факто. Сегодня без API не работает ни одна крупная платформа: Meta, Google, Яндекс, AmoCRM, Битрикс24 — все предоставляют API для интеграции с внешними системами. По данным отчета MuleSoft Connectivity Benchmark, компании в среднем используют более 900 приложений, и подавляющее большинство из них связаны между собой именно через API.

В маркетинге API — основа любой сквозной аналитики. Google Analytics 4 принимает события через Measurement Protocol API, а рекламные системы получают конверсии через Conversions API у Facebook/Meta (CAPI) и аналоги у Яндекса. Когда настраиваете автоматическую стратегию в Директе, алгоритм учитывает не только клики, но и офлайн-конверсии — заявки из CRM, передаваемые через API. Без этой передачи алгоритм видит неполную картину и оптимизируется хуже. Отдельная история — маркетплейсы: продавцы на Wildberries, Ozon и Яндекс.Маркете управляют ценами, остатками и рекламой через API этих платформ. При ассортименте больше 200 позиций ручное управление становится физически невозможным — API здесь не опция, а необходимость.

Маркетолог, который понимает, как работает API, ставит технические задачи разработчику точнее и быстрее получает результат. Вместо расплывчатого «сделай интеграцию CRM и рекламы» он говорит: «каждые 30 минут делай GET-запрос к AmoCRM, бери сделки со статусом 160 (Выиграна), передавай их как офлайн-конверсию purchase в Google Ads API с ценностью из поля budget_total». Когда интеграция ломается — а это происходит регулярно из-за смены версий API — маркетолог, понимающий структуру, быстро диагностирует проблему по коду ошибки: 401 — проблема с авторизацией, 429 — превышен лимит запросов, 500 — сервер поставщика недоступен. Наконец, часть API-интеграций сегодня собирается без разработчика — через Zapier, Make или встроенные коннекторы в CRM, и понимание принципов API напрямую влияет на то, что маркетолог может автоматизировать самостоятельно.

Как работает API

1. Клиент формирует HTTP-запрос. Каждый запрос к API содержит четыре ключевых элемента: метод (GET — получить данные, POST — создать, PUT/PATCH — обновить, DELETE — удалить), URL-адрес ресурса (endpoint), заголовки (headers, например авторизационный токен) и тело запроса (body, обычно в формате JSON). Запрос GET https://api-direct.yandex.ru/v5/campaigns с заголовком Authorization: Bearer возвращает список рекламных кампаний аккаунта. Endpoint — это не адрес страницы, а адрес ресурса или действия: /campaigns, /reports, /bids — каждый путь ведет к своему типу данных.
2. Сервер проверяет подлинность запроса. Прежде чем обрабатывать запрос, API-сервер проверяет, кто его отправил и есть ли у отправителя право на это действие. Наиболее распространенные методы: API-ключ (статическая строка в заголовке или параметре URL), OAuth 2.0 (протокол, через который Google, Facebook и Яндекс выдают временные токены с ограниченным сроком жизни), Basic Auth (логин и пароль в base64-кодировке — именно этот метод использует WordPress REST API). Если авторизация не прошла, сервер возвращает код 401 Unauthorized и не выполняет запрос.
3. Сервер выполняет запрашиваемое действие. После проверки прав сервер запускает бизнес-логику: ищет данные в базе, фильтрует по переданным параметрам, создает или обновляет записи. Запрос к API Яндекс.Метрики с параметрами date1=2024-01-01&date2=2024-01-31&metrics=ym:s:visits заставляет сервер посчитать визиты за январь по всем источникам и подготовить ответ. Сложные агрегации выполняются на стороне сервера — это снижает объем передаваемых данных.
4. Сервер возвращает структурированный ответ. Ответ содержит HTTP-код статуса и тело ответа. Основные коды: 200 — успех, 201 — ресурс создан, 400 — ошибка в запросе (неверные параметры), 401 — не авторизован, 404 — ресурс не найден, 429 — превышен лимит запросов, 500 — внутренняя ошибка сервера. Тело ответа приходит в JSON или XML: для REST API это почти всегда JSON — массив объектов или один объект с полями. Зная структуру ответа из документации заранее, разработчик точно знает, какие поля ожидать.
5. Клиент разбирает ответ и использует данные. Получив JSON, приложение-клиент разбирает его — извлекает нужные поля и использует в своих целях: показывает в дашборде, записывает в базу данных, передает в следующий сервис по цепочке. Скрипт выгрузки статистики берет из ответа Метрики поле visits и пишет значение в Google Sheets. Здесь важна обработка вложенности: JSON бывает многоуровневым, и нужное значение может лежать внутри нескольких вложенных объектов.
6. Скрипт обрабатывает ошибки и соблюдает лимиты. Любая production-интеграция должна уметь корректно реагировать на коды ошибок. Получили 429 — остановитесь на несколько секунд и повторите запрос, применяя экспоненциальную паузу (1с, 2с, 4с, 8с). Яндекс.Директ API разрешает не более 5 запросов в секунду и 40 000 операций в сутки — скрипт, игнорирующий эти ограничения, получит временный бан. Грамотная обработка ошибок и соблюдение лимитов — разница между интеграцией, которая работает год без вмешательства, и той, которую нужно перезапускать каждую неделю.

Виды API

• REST API. Самый распространенный тип в веб-разработке и маркетинге. Работает поверх HTTP, данные передает в JSON, не хранит состояние между запросами. Почти все рекламные платформы (Google Ads, Яндекс.Директ, VK Ads), аналитические сервисы и CRM предоставляют именно REST API. Если в документации написано просто «API» без уточнения — почти наверняка речь о REST.
• SOAP API. Протокол на основе XML, разработанный в конце 1990-х. Строже REST: каждый запрос и ответ описывается WSDL-схемой (Web Services Description Language), что дает строгую типизацию и встроенные стандарты безопасности. Распространен в банковских системах, страховых компаниях и государственных информационных системах — например, в API ФНС для работы с электронными документами. Для маркетолога SOAP актуален при работе с банковскими или государственными системами.
• GraphQL. Альтернативный подход, разработанный Facebook в 2012 году и открытый публично в 2015-м. В отличие от REST, где сервер определяет структуру ответа, в GraphQL клиент сам указывает, какие поля хочет получить — это исключает избыточную передачу данных. Вместо объекта кампании с 40 полями вы запрашиваете только name, budget и status. Instagram и Shopify используют GraphQL API, и для разработки под эти платформы понимание этого подхода необходимо.
• Webhook. Технически это «обратный API» — не ваш код опрашивает сервис по расписанию, а сервис сам уведомляет вас о событии. Вы указываете URL своего сервера, и при событии (новый заказ, оплата, смена статуса) сервис отправляет POST-запрос с данными на этот адрес. AmoCRM отправляет webhook при создании сделки, Stripe — при успешной оплате. Для маркетолога это означает мгновенную передачу конверсий: событие произошло — данные сразу попали в систему без задержки.
• Публичный (Public) API. Открытый для всех разработчиков интерфейс, доступный после регистрации и получения ключа. Такой API предполагает строгую документацию, версионирование и публично объявленные лимиты. Примеры: API HeadHunter для поиска вакансий, API DaData для проверки и обогащения адресов и телефонов, API Яндекс.Карт для встраивания карт. Публичные API часто бесплатны до определенного объема запросов, далее переходят на платные тарифы.
• Внутренний (Private) API. API, который компания создает только для своих продуктов — мобильного приложения, внутренней аналитики, взаимодействия между микросервисами. Пользователи не видят документацию такого API, но он работает за каждым действием в приложении: нажали кнопку «Купить» — приложение вызвало внутренний API сервиса оплаты. Для маркетолога понимание этого типа полезно при постановке задачи разработчикам на создание внутреннего инструмента аналитики.

Сравнение REST API и веб-парсинга

Пример использования

Онлайн-сервис бронирования корпоративных командировок работал с командой из трех менеджеров, которые обрабатывали запросы на бронирование вручную: заходили на партнерские порталы, проверяли наличие и цены, отвечали сотруднику компании-клиента. Средний цикл обработки одного запроса составлял 2.5 часа. При потоке 25-30 запросов в рабочий день конверсия из запроса в подтвержденное бронирование держалась на уровне 22% — остальные уходили к конкурентам, которые отвечали быстрее. Ежемесячный оборот не превышал 1.4 млн рублей, а масштабирование без найма новых менеджеров было невозможным.

Разработчики интегрировали сайт с API поставщика гостиничного контента: актуальные цены и наличие номеров стали отображаться на сайте в реальном времени, бронирование стало проходить без участия менеджеров. Цикл обработки упал с 2.5 часов до 4 минут — времени, которое пользователь тратит на заполнение формы. За первый полный месяц работы интеграции конверсия из запроса в бронь выросла с 22% до 38% (+73%), средний чек увеличился на 12% (пользователи получили возможность самостоятельно сравнивать варианты), оборот достиг 2.5 млн рублей (+79%) при тех же рекламных бюджетах. Три менеджера перенаправили 80% времени с обработки стандартных броней на работу с ключевыми корпоративными клиентами.

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