GigaChat перевёл новые подключения на единый адрес API

Документация GigaChat API 17 июля 2026 года закрепила https://api.giga.chat как целевой адрес для новых подключений физических и юридических лиц. Прежний адрес остаётся доступен существующим интеграциям, но больше не используется для новых подключений и в дальнейшем должен быть выведен из эксплуатации.

Что именно изменилось

Изменение относится к базовому адресу запросов к моделям. В официальном примере список моделей запрашивается через https://api.giga.chat/v1/models. Разработчик рекомендует действующим клиентам запланировать переход со старого адреса.

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

Документация также указывает, что токен доступа действует 30 минут, а при его получении для разных вариантов обслуживания используются соответствующие значения scope. Эти параметры нужно сохранить при миграции.

Почему небольшое изменение требует полноценной проверки

Смена базового URL выглядит как простая конфигурационная правка, однако она затрагивает несколько инфраструктурных слоёв:

• правила межсетевого экрана и разрешённые домены;
• корпоративный прокси, DNS и проверку TLS-сертификата;
• секреты и переменные окружения в разных контурах;
• SDK, в которых старый адрес мог быть значением по умолчанию;
• мониторинг, трассировку и фильтрацию журналов;
• тесты доступности и инструкции дежурной команды.

Если адрес зашит в исходный код нескольких сервисов, миграция становится поводом вынести его в централизованную конфигурацию. Это упростит следующую смену маршрута и позволит раздельно управлять production, тестовым контуром и резервным сценарием.

Безопасный план переноса

Для корпоративной интеграции разумно провести переход по этапам:

1. Найти все упоминания старого домена в коде, CI/CD, секретах, прокси и документации.
2. Разделить настройки OAuth и inference API, не смешивая их в одной переменной.
3. Разрешить новый домен в сетевых политиках тестового контура.
4. Проверить получение токена, список моделей и основной запрос с обезличенными данными.
5. Сравнить коды ошибок, задержку, потоковую передачу и обработку лимитов.
6. Перевести небольшую долю нагрузки и наблюдать за метриками.
7. Обновить runbook и только затем убрать зависимость от старого адреса.

Старый URL пока остаётся доступным, но источник не называет точную дату его отключения. Это снижает срочность аварийной замены, но повышает ценность плановой миграции до того, как появится жёсткий срок.

Что изменение не гарантирует

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

Команде стоит хранить идентификатор модели отдельно от базового URL, фиксировать версию SDK и иметь набор регрессионных запросов. Для чувствительных бизнес-процессов нужен контроль формата ответа, ограничения на действия модели и ручное подтверждение там, где ошибка может повлиять на клиента или операцию. Практические меры для инструментов, прав и аудита разобраны в статье о безопасной архитектуре ИИ-агентов.

Практический итог для B2B

Обновление GigaChat API — не новый продукт, а инфраструктурное изменение жизненного цикла уже работающих интеграций. Его ценность для ИТ-команды в том, что переход можно провести заранее и без остановки сервиса. Главные задачи — разделить адреса авторизации и модели, проверить сетевой контур, убрать жёстко заданные значения и подтвердить поведение приложения на тестовом трафике.

Источник: официальная документация GigaChat API, обновлённая 17 июля 2026 года.