Пока действие происходит внутри одного сайта, хватает страницы, кнопок и форм. Но сложные действия быстро выходят за границы одного сервиса. Например, клиент оставил заявку на лендинге. Ее нужно отправить в CRM, создать счет в платежном сервисе, записать событие в таблицу и прислать менеджеру сообщение в Telegram. Ни один сайт сам по себе такую цепочку не соберет. Сервисы нужно соединить между собой.
Для этого и нужен API. Это способ, которым программы разговаривают с сайтами и передают друг другу данные. Когда вы просите агента собрать такую цепочку, он ищет, какие API есть у нужных сервисов, и соединяет их в одно действие.
Как это работает Сайты и сервисы в интернете создаются не только для людей. У каждого популярного сервиса есть посетители, которых вы никогда не увидите глазами. Это другие программы. Чужие сайты, мобильные приложения, разнообразные боты и скрипты автоматизации. Им тоже нужны данные сервиса, но в машиночитаемом виде.
{ "rate": 75.42 } — чистые данные для обработкиПоэтому сервис открывает второй вход, рассчитанный на программы. Через него можно запросить те же данные, но без оформления, в виде фиксированных структур данных. Этот вход и называется API.
Возьмем курс доллара. Человек заходит на сайт банка, находит нужную строку и читает число глазами. Программа на сайт не заходит. Она отправляет короткий запрос на специальный адрес банка и в ответ получает готовое число. Та же
информация, но добытая без единого клика. Приходит она в структурированном виде, чаще всего в формате JSON.
А вот сам обмен запросом и ответом, когда к API обращается программа.
← ответСервис ЦБ{ "rate": 75.42 }
У API обычно есть отдельный адрес. Программа отправляет запрос на этот адрес и получает ответ с данными.
GET https://api.example.com/products?category=coffee
GET используют, когда хотят получить данные. POST используют, когда хотят отправить данные в сервис. Например, получить список товаров это GET , а создать новый заказ это POST . В адресе после вопросительного знака часто передают уточнение, какие именно данные нужны.
Зачем это знать. Современные приложения почти всегда собираются из готовых кубиков, и эти кубики соединяются через API. Платежи через ЮKassa, авторизация через Яндекс ID, рассылка писем через Unisender. Каждый такой сервис дает API, через который ваше приложение с ним работает. Когда вы просите агента "добавь оплату на сайт", он подключит чей-то API. Когда просите "пришли уведомление в Telegram", он опять обратится к API Telegram.
В каком виде сервисы возвращают данные Когда сервис отвечает на ваш запрос, он не возвращает HTML-страницу, как браузер. Он возвращает структурированные данные в стандартном формате, который понимают все языки программирования.
Самый частый формат называется JSON. Внутри пары из имени и значения, собранные во вложенные блоки.
{
"currency": "USD",
"rate": 75.42,
"updated": "2026-06-13"
}Иногда встречается YAML. То же содержимое, без скобок и кавычек, с отступами. На YAML обычно пишут конфиги. Ответы API в этом формате приходят редко.
currency: USD rate: 75.42 updated: 2026-06-13
Бывает и XML. Это старый формат с тегами, как в HTML. Сейчас его отдают в основном банковские, государственные и корпоративные сервисы, выпустившие свой API лет десять-пятнадцать назад.
<currency> <code>USD</code> <rate>75.42</rate> </currency>
Подробнее про JSON JSON похож на небольшой словарь. Слева стоит имя поля, справа значение. Имя всегда пишется в кавычках. Значение может быть строкой, числом, логическим значением, пустым значением, массивом или вложенным объектом.
{
"title": "Новый заказ",
"amount": 4900,
"paid": true,
"comment": null
}Строки пишутся в кавычках. Числа пишутся без кавычек. true и false означают "да" и "нет". null означает, что значения сейчас нет. Например, клиент еще не оставил комментарий или сервис еще не знает дату доставки.
Массив нужен, когда значений несколько. В заказе может быть несколько товаров, у статьи несколько тегов, у пользователя несколько ролей.
{ "orderId": 125, "items": [ "Кофе", "Фильтры", "Кружка" ] }
В реальных API внутри массива чаще лежат не строки, а объекты. Так сервис передает список одинаковых сущностей.
{
"orderId": 125,
"items": [
{
"name": "Кофе","price": 700, "quantity": 2 }, { "name": "Фильтры", "price": 300, "quantity": 1 } ] }
Это и есть вложенность. Объект может лежать внутри другого объекта, массив может лежать внутри объекта, а внутри массива могут лежать новые объекты. За счет этого JSON описывает не только одно число вроде курса доллара, но и сложные вещи вроде заказа, сделки в CRM или расписания вебинара.
Когда агент показывает вам ответ API, не надо читать JSON как код. Смотрите на имена полей и форму данных. Где одно значение, где список, где вложенный блок. Этого хватает, чтобы понять, что сервис вернул и какое поле нужно передать дальше в автоматизацию.
Парсинг API есть не у всех сайтов. Иногда цены, новости, объявления или отзывы доступны только на обычных страницах для людей. Сервис не дает отдельный адрес с готовыми данными, поэтому программе приходится открывать страницу как браузер, читать HTML и вытаскивать нужные куски. Это называется парсингом.
В общих чертах это работает так. Скрипт открывает каталог конкурента, читает HTML страницы, находит на ней карточки товаров и для каждой вытаскивает название и цену. Результат складывает в таблицу. Как именно искать нужные куски на конкретной странице, разбираться вам не нужно, это задача агента.
Тем же способом решают и соседние задачи. Следить за ценами и ловить момент, когда конкурент их меняет. Собирать объявления по своему городу в одну таблицу. Снимать отзывы о товаре с разных площадок. Везде, где нужные данные лежат на чужих страницах и собирать их руками слишком долго, подходит парсинг.
У парсинга есть слабое место. Он завязан на то, как сверстана страница. Стоит конкуренту поменять дизайн каталога, и парсер перестает находить цены, его приходится чинить. Поэтому перед парсингом сначала ищите официальный API, RSS или другой фид с данными.
RSS и поток обновлений с сайтов API решает много задач, но есть он не у всех сайтов. У некоторых сайтов вместо API есть RSS. Это специальная страница, где сайт перечисляет новые записи в стандартном виде.
RSS часто встречается у блогов, СМИ, подкастов и страниц релизов. Хабр отдает RSS, GitHub отдает RSS для релизов, у многих корпоративных блогов адрес фида выглядит как /feed или /rss .
Как выглядит RSS изнутри. Это XML-файл со списком записей.
<rss> <channel> <title>Блог Acme</title> <item> <title>Запустили новую интеграцию</title> <link>https://acme.ru/posts/integration</link> <pubDate>Wed, 11 Jun 2026 10:00:00 +0300</pubDate> <description>Теперь данные...</description> </item> <item> <title>Обновили тарифы</title> <link>https://acme.ru/posts/pricing</link> <pubDate>Mon, 09 Jun 2026 14:30:00 +0300</pubDate> <description>Снизили цены на...</description> </item> </channel> </rss>
Каждый <item> это одна запись на сайте. Внутри название, ссылка, дата публикации и краткое описание. Когда сайт публикует новую запись, она появляется в начале списка. Программа, которая раз в час заглядывает в этот файл, видит свежие записи и забирает только то, что появилось после прошлой проверки.
Похожая идея используется в Яндекс Маркете. Интернет-магазин публикует XML-фид с товарами, ценами, наличием и ссылками на картинки. Маркет заходит по этому адресу и забирает каталог в стандартном виде. Это уже не блоговая RSS- лента, но принцип тот же. Данные лежат в отдельном машиночитаемом файле, поэтому их не приходится выковыривать из HTML-страницы.
RSS не заменяет полноценный API, но хорошо подходит для задачи "узнать, что появилось нового". Перед тем как парсить чужой сайт, проверьте, нет ли у него RSS. Это работает быстрее, не требует обхода защит и не ломается при редизайне.
Самостоятельная работа В этом задании вы сделаете мини-страницу с курсом валют и погодой. Это типичный вайбкодерский сценарий: взять данные из чужих сервисов и собрать из них полезный экран.
Страница в Claude Artifact
Откройте Claude и дайте задачу.
Сделай Artifact с мини-дашбордом "Курс валют и погода в Москве". На странице должны быть карточки USD, EUR, температура, осадки и время обновления. Курс валют бери из открытого API https://www.cbr-xml- daily.ru/daily_json.js , погоду бери из Open-Meteo для Москвы. Добавь кнопку "Обновить", которая заново запрашивает данные. Если один из API не ответил, покажи понятное сообщение об ошибке на самой странице.
После ответа откройте Artifact. Нажмите кнопку обновления и посмотрите, что значения на странице меняются или хотя бы заново загружаются без правки текста вручную.
Проверьте источник данных
Откройте адрес с валютами в отдельной вкладке:
https://www.cbr-xml-daily.ru/daily_json.js
Найдите в JSON поля USD и EUR . Сравните значения с тем, что показывает Artifact. Потом откройте промпт с кодом страницы и найдите адрес Open-Meteo. В нем должны быть координаты Москвы и параметры погоды.
Проверка: на странице видны USD, EUR, температура, осадки и время обновления. В коде есть два запроса к API, а цифры на странице не вписаны руками.
Доработайте вид
Попросите Claude сделать страницу удобнее.
Улучши этот Artifact: добавь подписи "курс ЦБ" и "погода Open-Meteo", сделай состояние загрузки, а под карточками покажи короткую строку "данные получены из внешних API".
Проверка: при открытии страницы сначала видно загрузку, потом карточки с данными. Если отключить интернет или API временно недоступен, страница показывает ошибку, а не пустой экран.
Дополнительные материалы Что такое API простыми словами