Смена домена/URL подписки заголовком ответа (аналог new-domain)

Автор: e**********@gmail.com

Продукт: Приложение INCY

Создан: 07.10.2026, 10:53:34

Версия ОС: IOS 27

Модель устройства: Iphone 17 pro

Мы провайдер, используем INCY в проде, домены подписки верифицированы в кабинете.

ЗАДАЧА

Мы развели свои проекты по отдельным доменам подписки — раньше все жили на одном общем.
Новым пользователям бот выдаёт ссылку сразу на нужном домене, а уже установленные подписки
переписать не получается: в приложении нет способа сменить домен или URL существующей подписки
со стороны провайдера. Для пользователя это означает «удали подписку и добавь заново».

ЧТО УЖЕ ПОПРОБОВАЛИ И ПОЧЕМУ НЕ ПОДОШЛО

1. Заголовок new-domain (его понимает Happ) — INCY его игнорирует. Ваша поддержка подтвердила,
   что аналога нет, и предложила оформить фичреквест.
2. fallbackHosts из Premium API — это механизм на случай ОТКАЗА основного домена, а не плановый
   перенос: переключение происходит, только когда основной домен не отвечает, и список задаётся
   на уровне провайдера, а не конкретной подписки. Для управляемой миграции не годится.
3. Deep link incy://add/{url} — требует действия пользователя и, насколько мы понимаем, создаёт
   рядом вторую карточку подписки вместо обновления существующей.

ЧТО ПРОСИМ

Поддержать смену адреса подписки заголовком ответа — по аналогии с тем, как у вас уже работают
hide-url, banner-*, profile-web-page-url, то есть на уровне конкретной подписки:

    new-domain: example.com
        меняется только хост, путь и токен подписки сохраняются

    new-url: https://example.com/<token>
        полная замена адреса, если меняется и путь

Ожидаемое поведение: при очередном обновлении подписки клиент переписывает её URL на новый и
дальше ходит уже туда. Без диалогов и без участия пользователя, существующая подписка
обновляется, а не дублируется.

КЛЮЧЕВОЕ: ЗНАЧЕНИЕ ДОЛЖНО БЫТЬ ПРИВЯЗАНО К ПОДПИСКЕ, А НЕ К ПРОВАЙДЕРУ

У нас одна панель и один providerid, но разные группы пользователей (сквады) отдают РАЗНЫЕ
домены — у каждого проекта свой. Поэтому просим, чтобы клиент применял ровно то значение,
которое пришло в ответе ЭТОЙ подписки, и не распространял его на другие подписки того же
провайдера и не кэшировал как «домен провайдера» глобально.

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

ВАЖНО ДЛЯ БЕЗОПАСНОСТИ

Просим применять смену только если новый домен верифицирован в кабинете ТОГО ЖЕ провайдера
(domain_hash, как при проверке providerid). Тогда чужой origin не сможет увести подписку на свой
адрес. Если домен не верифицирован или совпадает с текущим — заголовок игнорируется.

Если заголовок по каким-то причинам неудобен, нас устроит и эквивалент в Premium API — рядом с
fallbackHosts, но с привязкой к конкретной подписке, а не ко всему провайдеру.

ЗАЧЕМ ЭТО НУЖНО НЕ ТОЛЬКО НАМ

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