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

Изначально это был API-first проект в прямом смысле слова.

Он не просто “что-то искал через API”.
Через официальный соискательский контур HH у меня был собран почти весь рабочий цикл: OAuth-авторизация, access token, поисковые конфиги, получение вакансий, чтение деталей, генерация сопроводительных, отправка откликов, логирование результатов, обновление статусов и работа с историей через /negotiations.

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

Это была уже не заготовка, а нормальная система откликов, построенная на официальном канале.

Потом HH этот канал закрыл.

Они написали это прямо:
«Прекращаем поддержку соискательского API»,
«С 15 декабря доступ к соискательскому API hh будет закрыт»,
«К сожалению, альтернативных форматов работы с соискательским API нет».

Объяснение тоже было прямым: безопасность, прозрачность, поток нерелевантных автооткликов, мошеннические практики и риски доступа к данным.

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

То есть одна сторона рынка продолжает работать через автоматизацию, интеграции и машинные контуры.
Другая осталась без официального программного канала вообще.

И в этот момент проект столкнулся с архитектурным ударом.

До этого модель была такой:

API search
API details
API apply
API statuses

После этого пришлось собирать другую:

browser search
browser details
browser apply
Telegram-first handoff
state, retry, safety

Именно здесь выяснилось, есть ли у проекта запас прочности.
Может ли он пережить исчезновение официального пути, не потеряв собственную логику.

Это был момент, когда проект либо умирает вместе с закрытым API, либо взрослеет.

Я выбрал второе.