HH.ru закрыл публичный API поиска вакансий: что это значит и к чему готовиться разработчикам и аналитикам
С апреля 2026 года один из самых удобных инструментов для работы с данными о рынке труда перестал быть доступен широкой аудитории. Публичный метод GET /vacancies в API HeadHunter начал возвращать ответ 403 Forbidden для неавторизованных запросов. Формально API продолжает существовать, но фактически превратился в закрытый инструмент для ограниченного круга пользователей.
Раньше ситуация была куда проще: чтобы строить дашборды, экспериментировать с парсингом вакансий или анализировать динамику спроса на профессии, достаточно было отправлять запросы к открытому методу поиска вакансий. Многие разработчики, аналитики и энтузиасты рынка труда именно так и делали: писали скрипты, собирали данные в базы, строили собственные отчёты и графики.
Неудивительно, что в апреле многие заметили странное поведение своих сервисов: привычные графики перестали обновляться, дашборды замерли, а скрипты, годами работавшие без вмешательства, внезапно начали падать с ошибками авторизации. Кто‑то откладывал разбор проблемы "на потом", считая, что речь о временных сбоях. Однако выяснилось, что изменения носят системный характер: эпоха действительно закончилась.
Что изменилось формально
Главное изменение - публичный (анонимный) доступ к поиску вакансий больше не работает. Теперь:
- Неавторизованные запросы к GET /vacancies получают 403 Forbidden.
- Для получения ключа доступа требуется:
- подтверждённый аккаунт работодателя;
- регистрация приложения;
- прохождение модерации.
- Фактически, ориентир сместился на компании и рекрутинговые сервисы, а не на частных разработчиков и исследователей.
То есть любой скрипт или дашборд, который отправлял запросы без полноценной авторизации работодателя, оказался отрезан от источника данных.
Почему это важно именно для "частной" аналитики
Для бизнеса, который официально работает с платформой как работодатель или рекрутинговый сервис, последствия не столь драматичны: при наличии аккаунта и одобренного приложения доступ к данным остаётся, пусть и в более формализованном виде.
Для частных лиц ситуация другая. Речь о:
- разработчиках, которые строили пет‑проекты и учебные дашборды;
- аналитиках данных, использовавших вакансии как "живой" источник для экспериментов;
- специалистах, изучающих динамику рынка труда (компетенции, зарплатные вилки, географию спроса);
- соискателях, собирающих персональную аналитику по интересующим позициям.
Для этих сценариев "легальный публичный способ автоматически собирать вакансии" практически исчез. Да, теоретически никто не мешает зарегистрировать аккаунт работодателя, но это уже другой уровень формальности и ответственности, а иногда и просто невозможность - не у всех есть реальная компания и потребность в размещении вакансий.
Зачем вообще нужен был этот публичный API
Публичный API поиска вакансий выполнял сразу несколько функций:
- Учебный полигон. Идеальный источник "живых" данных для изучения REST, ETL/ELT, построения витрин, BI‑дашбордов.
- Исследования рынка труда. Аналитики могли отслеживать, как меняется спрос на языки программирования, технологии, должности, уровни зарплат.
- Личные инструменты. Кто‑то фильтровал вакансии по своим сложным критериям, кто‑то настраивал уведомления, более гибкие, чем встроенные средства сайта.
- Портфолио для data‑engineer'ов и разработчиков. Реальные пет‑проекты с интеграцией с крупным сервисом выглядели в разы убедительнее, чем абстрактные задачки.
Закрытие анонимного доступа бьёт в первую очередь по этим сценариям: самостоятельные исследователи и начинающие специалисты теряют удобную "песочницу".
Может ли что-то заменить старый режим работы
Полного аналога публичному поисковому API сейчас нет. Возможны лишь частичные компромиссы:
1. Авторизованный доступ через аккаунт работодателя.
Подходит тем, у кого есть реальный статус работодателя и необходимость в интеграциях. Но:
- требуется модерация приложения;
- использование API придётся согласовывать с правилами сервиса;
- формально это канал для решения бизнес‑задач по найму, а не для внешней аналитики.
2. Сохранённые исторические данные.
У кого‑то остались уже собранные дампы вакансий за прошлые годы. Их всё ещё можно:
- использовать для обучения и демонстрации навыков;
- комбинировать с другими источниками;
- строить ретроспективный анализ (тренды до 2026 года).
3. Альтернативные источники данных.
Можно искать открытые данные о рынке труда в других сервисах, официальной статистике, отраслевых отчётах. Они, как правило:
- менее детальны;
- реже обновляются;
- предоставляются в агрегированном виде, а не на уровне отдельных вакансий.
4. Синтетические и полусинтетические датасеты.
Для учебных задач иногда достаточно частично анонимизированных или сгенерированных наборов данных, отражающих структуру вакансий. Это уступает реальным данным, но помогает отрабатывать технические навыки.
Почему просто "спарсить" сайт - плохая идея
После закрытия публичного API многим приходит в голову очевидное решение: раз API больше не пускает, можно брать данные напрямую со страниц сайта. С технической точки зрения это возможно, но:
- нарушает пользовательское соглашение сервиса;
- может привести к блокировке аккаунта и IP;
- неустойчиво - любая правка HTML‑структуры ломает парсер;
- часто противоречит политике обработки и защиты персональных данных.
В результате любой подобный "обход" превращается в серую зону, где риски для разработчика и компании многократно превосходят выгоду. Для учебных проектов и особенно для публичных сервисов подобный подход едва ли оправдан.
Что делать, если у вас был дашборд или аналитика по вакансиям
Если ваш проект, как и у многих, "умер" в апреле 2026 года вместе с публичным доступом к GET /vacancies, можно рассмотреть несколько шагов:
1. Зафиксировать историческую часть.
Сделать акцент на том, что ваш дашборд - ретроспективный анализ за конкретный период. Это всё равно ценная работа: пайплайны, модель данных, визуализации.
2. Перепрофилировать проект.
- Добавить новые источники (другие площадки, открытые отчёты, статистику);
- сравнивать рынки между собой;
- сместить акцент с "онлайн‑мониторинга" на "глубокую аналитическую выжимку".
3. Переориентироваться на синтетические/обезличенные данные.
Для демонстрации технических навыков важнее архитектура решения, чем конкретный источник. Можно:
- воссоздать структуру данных вакансий;
- описать, как выглядел бы реальный коннектор к API;
- показать пайплайны обработки, даже если источник теперь "виртуальный".
4. Описать в портфолио ограничения.
В резюме или описании проекта честно указать: "Проект работал с публичным API до его закрытия. Сейчас - демонстрация архитектуры и исторических данных". Для опытного работодателя это понятная ситуация.
Как это повлияет на рынок специалистов по данным и разработчиков
Закрытие удобного публичного источника - неприятный, но показательный сигнал:
- усиливается тренд на закрытость данных крупных платформ;
- растёт роль официальных партнёрств и интеграций;
- "самодеятельный" сбор данных постепенно вытесняется юридически выверенными каналами.
Для data engineer'ов, аналитиков и разработчиков это означает:
- придётся чаще работать с формализованными договорами и ограничениями по использованию данных;
- возрастает ценность навыков интеграции с корпоративными API, а не только с "игрушечными" публичными;
- портфолио‑проекты всё сильнее будут смещаться либо к полностью открытым датасетам, либо к синтетике.
Почему можно говорить о "конце эпохи"
Публичный API вакансий долгое время был не просто техническим инструментом, а символом открытости части рынка труда для разработчиков и аналитиков. Он позволял:
- буквально "потрогать руками" реальный спрос на навыки;
- быстро проверять гипотезы (от зарплатных ожиданий до географических кластеров);
- строить свои маленькие "аналитические отделы" в одиночку.
С переходом к авторизационной модели и жёсткой модерации доступ к этим возможностям стал привилегией компаний, а не обычных специалистов. В этом смысле действительно можно сказать: прощай, эпоха открытого, простого и массового анализа вакансий в автоматическом режиме.
Чему можно научиться на этом кейсе
История с закрытием публичного API полезна как минимум в трёх аспектах:
1. Не полагаться безоговорочно на "чужую инфраструктуру".
Любой внешний сервис может в любой момент изменить правила игры. В архитектуре проектов стоит:
- закладывать возможность смены источников;
- разделять слой данных и логику работы с ними.
2. Учитывать юридический контекст работы с данными.
Работоспособность API - это ещё не гарантия, что его можно использовать как угодно. Важно:
- читать условия использования;
- понимать ограничения по объёму, целям и типам обработки.
3. Ценить открытые датасеты и инициативы.
Каждый открытый набор данных - ресурс, который может исчезнуть или ограничиться. Пока он доступен, имеет смысл:
- документировать свой опыт работы с ним;
- сохранять обезличенные копии для обучения (если это не противоречит правилам).
***
Сейчас реальность такова: публичного, неавторизованного способа регулярно и легально собирать данные о вакансиях для личной аналитики практически больше нет. Рынок движется в сторону закрытых API, партнёрских программ и строго регламентированных интеграций. Для специалистов это не повод опускать руки, но сигнал пересматривать подход к данным: думать не только о том, "как достать", но и о том, "как иметь право использовать" и "что делать, если завтра кран перекроют".
