GitHub: временный заголовок для принудительного формата токенов установки приложений

GitHub объявил в апреле 2026 года о поэтапном переходе на новый формат токенов установки для GitHub App. Пока роллаут распространяется по серверам, разработчикам доступен временный HTTP‑заголовок X — GitHub-Stateless-S2S-Token, который в единичном запросе переопределяет серверное решение и позволяет форсировать выдачу нужного формата токена — это важно для проверки работоспособности приложений и рабочих процессов до того, как переключение достигнет вашей интеграции. Заголовок действует только для POST‑запроса к REST‑эндпоинту /app/installations/: installation_id/access_tokens и влияет лишь на конкретный вызов: он не изменяет глобальные настройки и не ускоряет общий роллаут. Значение заголовка управляет форматом ответа для данного запроса и применяется на стороне сервера как одноразовое переопределение решения о выдаче токена.

Поведение по значениям заголовка четко определено: значение enabled возвращает stateless‑токен в формате JWT независимо от того, дошёл ли роллаут до вашей интеграции; значение disabled возвращает stateful — классический непрозрачный (opaque) токен, даже если ваша интеграция уже включена в обновление. Если заголовок отсутствует, действует стандартное поведение роллаута. Любые другие значения (например, true, false, 1, 0 и т. п.) игнорируются без ошибки и приводят к обычному поведению rollout. Stateless‑токен оформлен как JWT с префиксом ghs_. По длине он заметно больше классического токена — примерно 520 символов — и содержит две точки, что отличает его от opaque‑формата. Эта техническая разница влияет на обработку токенов в приложениях и служит ключевым признаком для тестирования совместимости.

Чтобы заранее проверить интеграции, отправьте при создании installation access token заголовок X — GitHub-Stateless-S2S-Token: enabled, чтобы получить stateless‑токен и убедиться, что ваше приложение корректно его принимает и валидирует. Для получения stateful‑ответа используйте disabled. Для полного синтаксиса запроса и примеров следует обращаться к документации REST API по созданию installation access token — сам заголовок поддерживается именно на POST /app/installations/: installation_id/access_tokens. Краткое практическое замечание: используйте этот механизм до того, как роллаут автоматически изменит формат токенов для ваших интеграций — так вы заранее выявите и устраните возможные проблемы в обработке нового формата и минимизируете риски для рабочих процессов.