Парсинг или API: что выбрать для сбора данных

Нередко разговор начинается с вопроса: «А у них нет API? Тогда зачем парсинг?». Или наоборот: «Нам нужен парсер, API мы не пробовали». Оба вопроса разумны, но они решаются одним и тем же способом: сначала выясняется, какие данные нужны, потом — каким каналом их отдаёт владелец, и только потом выбирается инструмент.

Короткий ответ такой. Если владелец данных сам даёт официальный канал — API, готовую выгрузку или открытые данные — и в нём есть нужные поля, берите его. Он стабильнее, понятнее по условиям и обычно проще в сопровождении. Парсинг страниц нужен там, где такого канала нет или он не покрывает задачу. А в большинстве реальных проектов получается смесь: часть полей из API, остальное с открытых страниц.

Границы разбора. Мы не юристы, и это не юридическая консультация. Документацию hh.ru, Google Play и Банка России мы читали на 10 октября 2026 года; про API маркетплейсов опираемся на описания интеграторов и отмечаем это. Условия использования каждого API перед запуском нужно прочитать самим: они меняются.

Что такое API и что такое парсинг

API — это официальный интерфейс, через который программа запрашивает данные у сервиса: «дай заказы за вчера», «дай курс на дату». Ответ приходит в структурированном виде, обычно в JSON или XML, а доступ почти всегда требует ключа или токена и подчиняется условиям использования.

Парсинг — это автоматическое чтение того, что сайт показывает людям: страниц, таблиц, карточек. Сайт не готовил это как интерфейс для программ, поэтому данные приходится вытаскивать из разметки.

Между ними есть ещё два способа, о которых часто забывают:

• Готовая выгрузка. Файл или ссылка на файл, которую сервис отдаёт сам: прайс поставщика в CSV или YML, отчёт из личного кабинета, открытые данные ведомства.
• Внутренние запросы сайта. Страница сама подгружает данные в JSON, и эти запросы видны в браузере. Их иногда называют «скрытым API», но официального доступа в них нет: это тот же парсинг, просто удобнее разбирать.

Способ	Плюсы	Минусы	Условия
Официальный API	Структурированные данные, документация, предсказуемость	Нужен ключ, есть лимиты, часто отдаёт только ваши данные	Договор: условия использования API
Готовая выгрузка	Проще всего, ничего не нужно разбирать	Только то, что владелец решил отдать, обновляется по его графику	Условия того, кто отдаёт файл
Парсинг страниц	Видно всё, что видит человек	Ломается при смене вёрстки, нужна осторожность по нагрузке и закону	Закон и правила сайта, без договора
Внутренние запросы сайта	Быстро и аккуратно по структуре	Не документированы, могут измениться без предупреждения	Как у парсинга

Три вопроса, которые определяют способ

Первый вопрос: чьи это данные. Если ваши — заказы вашего магазина, отзывы на ваше приложение, статистика вашего аккаунта, — почти всегда лучше API или выгрузка из кабинета. Вы вправе их получать, а владелец площадки заинтересован, чтобы вы делали это через официальный интерфейс, а не нагружали сайт.

Второй вопрос: есть ли официальный канал с нужными полями. «Есть API» и «в нём есть то, что вам нужно» — разные вещи. Многие API отдают данные вашего кабинета и не отдают чужие. Это не недоработка: так устроены права доступа.

Третий вопрос: видны ли данные без входа и защиты. Если данные открыты любому посетителю, их можно собирать с соблюдением границ. Если для доступа нужен логин, платная подписка или прохождение проверки на бота, это граница, которую мы не переходим.

Шесть примеров

1. Свои данные на маркетплейсе: API кабинета

Продавцу нужны заказы, остатки и цены своего магазина на Wildberries или Ozon. Здесь парсить нечего: у маркетплейсов есть API для продавцов. По описаниям интеграторов, доступ выдаётся из личного кабинета: у Wildberries — персональный токен для собственной интеграции или OAuth 2.0 для сервисов, подключающих чужие кабинеты, у Ozon ключ тоже создаётся в кабинете продавца. Такой ключ работает с данными вашей компании: товары, остатки, заказы, продажи, отчёты.

Зачем здесь парсинг? Незачем, и мы скажем об этом сразу. Данные точнее, чем на витрине, а доступ законный по определению: вы пользуетесь им по условиям площадки.

2. Цены конкурентов на витрине: парсинг открытых страниц

Те же цены, но чужих карточек. Мы не нашли у маркетплейсов официального метода, который отдавал бы продавцу цены конкурентов: API рассчитан на управление собственным магазином. Остаётся то, что видит любой покупатель на витрине. Такой сбор мы делаем в рамках границ: умеренная частота запросов, без обхода защиты, без данных людей. Подробнее об услуге — на странице «Мониторинг цен конкурентов».

Пример показывает главное: один и тот же маркетплейс даёт API для ваших данных и не даёт его для чужих, поэтому «нет ли у них API» — неполный вопрос.

3. Курсы валют, ставки, металлы: открытый XML

Для таких задач парсить сайт Банка России не нужно. Банк России отдаёт курсы на дату (XML_daily.asp), динамику курса за период (XML_dynamic.asp), цены на драгоценные металлы, межбанковские ставки и ставки по депозитам в виде XML, для большинства сервисов есть схемы. На странице с описанием сервисов про ключ или регистрацию не сказано.

Если нужны официальные цифры из такого источника, берите его, а не таблицу с новостного сайта, где те же числа переписаны вручную: ошибку в таблице вы не заметите, а официальный XML будет точным.

4. Вакансии: API hh.ru и условие «токен приложения»

Для анализа рынка труда нужны вакансии. У hh.ru есть открытая документация API на GitHub, и там ясно видно, как устроен доступ. Метод «Поиск по вакансиям» в ней помечен как требующий авторизации приложения, а не как анонимный. Если приложению нужен доступ к вакансиям, его регистрируют на сайте для разработчиков hh.ru. К запросам предъявляются требования: например, без заголовка User-Agent сервис отвечает ошибкой, а среди кодов ошибок есть и «необходимо пройти капчу». Есть и отдельные условия использования сервиса API.

Что из этого следует. Официальный путь существует, он законен и стабилен, но это не «скачал и пользуйся»: нужно зарегистрировать приложение, получить токен, принять условия и укладываться в лимиты. Для регулярной загрузки вакансий в свою систему он подходит, для разового среза бывает проще другой путь. Если задача шире, чем даёт API, например нужны признаки, которых нет в готовых полях, нужна обработка текста вакансий. Пример такой работы — мониторинг рынка вакансий. Подробнее об услуге — на странице «Анализ вакансий».

Заодно это пример того, что API живёт и меняется: в той же документации есть методы, помеченные как устаревшие, и новые возможности в них поддерживаться не будут.

5. Отзывы Google Play: API только для своего приложения

Если у вас есть приложение в Google Play, его отзывы можно получать через официальный API. Но у него есть рамки, и они видны в документации Google. Через него доступны отзывы только для production-версий и только с текстом комментария, отзывы же без текста через API не видны. Выдаются отзывы за последнюю неделю, а полную историю выгружают в CSV из консоли Google Play. Запросы идут по идентификатору вашего приложения от аккаунта разработчика с нужным разрешением. Квоты: 200 запросов на чтение в час на приложение, по умолчанию 10 отзывов на странице и не более 100 по параметру.

Для задачи «посмотреть, что пишут о приложениях конкурентов» такой доступ не подходит: у вас нет прав на чужие приложения. Здесь остаются открытые страницы магазина. Такой сборщик мы написали и опубликовали: сборщик отзывов Google Play, который не собирает людей, потому что имя автора превращается в хеш прямо при сборе.

6. Отзывы App Store: публичные интерфейсы Apple

Третий вариант — когда официальные публичные интерфейсы есть, но это не «API для разработчиков» с ключом. Наш парсер отзывов App Store работает через интерфейсы, которые Apple сама предоставляет для машинного доступа: RSS-фид отзывов, поиск и карточку приложения. Ни авторизации, ни обхода защиты. Это пример того, что граница между «API» и «парсингом» не всегда чёткая: источник предназначен для программ, но ключа не требует.

Внутренние запросы сайта: когда они подходят

Иногда страница сама подгружает данные в JSON, и разбирать их проще, чем вёрстку. Такой способ удобен, но надо понимать три вещи:

• Это не официальный доступ. Документации нет, формат могут изменить в любой день, и парсер сломается без предупреждения.
• Юридически это тот же парсинг открытых данных, с теми же границами: закон, правила сайта, умеренная нагрузка.
• Если запрос работает только с подписью, одноразовым токеном или после проверки на бота, это защита. Мы её не обходим. Если без обхода данные получить нельзя, мы не берёмся.

Что говорит закон

API — это договор. Ключ вы получаете на условиях владельца, и они обязывают вас: ограничивают цели использования, срок хранения, передачу данных третьим лицам. Перед запуском их стоит прочитать, особенно если вы планируете показывать или перепродавать результат. Для hh.ru, например, условия оформлены отдельным документом.

Парсинг открытых страниц опирается на ст. 7 закона «Об информации»: общедоступную информацию можно использовать «при соблюдении установленных федеральными законами ограничений». Эти ограничения — авторские права, права изготовителя базы данных, персональные данные. Подробно мы разобрали их в статьях «Законен ли парсинг сайтов» и «Парсинг новостей».

Официальный API не снимает требований закона. Если в ответе есть персональные данные, например резюме или профили людей, закон о персональных данных действует так же: нужны основание, локализация и минимум полей. Мы такие данные не собираем.

Нагрузка. У API она ограничена лимитами, и сервис сам отсекает лишнее. У парсинга лимит ставим мы, и от этого зависит, заметят ли нас: мы собираем в человеческом темпе.

Что надёжнее и что дешевле

Общего ответа нет, но по нашему опыту картина такая:

• Разовая задача. Часто быстрее получить срез с открытых страниц, чем регистрироваться, получать доступ и разбираться с лимитами официального API.
• Регулярная загрузка в вашу систему. Лучше API или выгрузка: интерфейс меняется реже и по документации, а ошибки заметны.
• Данные нужны глубже, чем даёт API. Берут API для основного и парсинг для остального.
• Сопровождение есть всегда. API меняют версии и закрывают методы, парсер ломается при смене вёрстки. Разница в том, что об изменениях API обычно предупреждают.

Как выбираем мы

Так мы подходим к каждой задаче:

1. Сначала ищем официальный канал: API, готовую выгрузку, открытые данные, публичные интерфейсы вроде тех, что у Apple.
2. Если он есть и покрывает задачу, говорим об этом сразу, даже если вы просили парсер. Продать парсинг проще, но заказчик, которому он не был нужен, второй раз не приходит.
3. Если канал есть, но данных не хватает, делаем гибрид: основное из API, недостающее с открытых страниц.
4. Если канала нет, собираем открытые страницы в границах закона: умеренная частота, без данных людей, без чужих текстов и фото, с учётом правил сайта.
5. Не обходим авторизацию, платный доступ, капчу и защиту запросов.
6. Перед оплатой показываем пробную выгрузку, чтобы вы увидели поля и качество на реальных данных.

Опишите задачу в контактах: какие данные, откуда и зачем. Мы скажем, какой канал подходит, и назовём цену и срок. Как сформулировать задачу, разобрано в статье «Как поставить задачу на парсинг», об услуге разового сбора — на странице «Парсинг сайтов».

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

Как понять, есть ли у сайта API?

Посмотрите разделы «Для разработчиков», «API» и «Партнёрам» в подвале сайта или в личном кабинете, поищите «название сервиса + API документация», проверьте, не даёт ли поставщик прайс файлом (CSV, XML, YML) по ссылке. Если ничего этого нет, официального канала, скорее всего, нет, но уточнить можно у поддержки сервиса.

Можно ли парсить сайт, у которого есть API?

Прямого запрета в законе мы не нашли, но есть практические причины предпочесть API: он стабильнее, а условия использования API прямо описывают, что можно. Если API покрывает задачу, парсинг только создаёт лишние риски и нагрузку. Если не покрывает, смотрите правила сайта и границы закона.

API платный?

Бывает всё: бесплатный в пределах лимитов, платный по тарифам, доступный только партнёрам. Это определяет владелец, поэтому условия нужно смотреть до расчёта проекта.

Что делать, если API закрыли или изменили?

Это обычный риск, поэтому важно, чтобы источник данных можно было заменить. Мы закладываем проверки качества выгрузки: если поле пропало или значения стали другими, вы узнаете об этом сразу, а не при очередном отчёте.

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

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

Источники

Данные собраны 10 октября 2026 года.

• hh.ru, документация API — github.com/hhru/api и dev.hh.ru
• Google, Reply to Reviews API — developers.google.com/android-publisher/reply-to-reviews
• Банк России, получение данных в формате XML — cbr.ru/development/SXML
• Wildberries API для продавцов, по описанию интегратора — selsup.ru
• Закон «Об информации, информационных технологиях и о защите информации», ст. 7 — Гарант
• Наши проекты: сборщик отзывов Google Play, парсер отзывов App Store, мониторинг рынка вакансий