GigaChat moves new API connections to a unified endpoint

On 17 July 2026, the GigaChat API documentation established https://api.giga.chat as the target endpoint for new individual and business connections. The previous address remains available to existing integrations but is no longer used for new connections and is expected to be retired in the future.

What has changed

The change applies to the base address used for model requests. The official example now retrieves the model list from https://api.giga.chat/v1/models, and existing customers are advised to plan a migration from the old address.

The same documentation still shows access-token retrieval through a separate OAuth endpoint. Teams should therefore not replace every domain in their configuration with a single search-and-replace operation: authentication and model API addresses serve different purposes.

The documentation also states that an access token is valid for 30 minutes and that the appropriate scope value is required for each service arrangement. These parameters must remain intact during migration.

Why a small URL change needs proper testing

A new base URL appears to be a simple configuration edit, but it touches several infrastructure layers:

• firewall allowlists and permitted domains;
• corporate proxies, DNS and TLS certificate validation;
• secrets and environment variables across deployment environments;
• SDKs that may still contain the old default address;
• monitoring, tracing and log filters;
• health checks and the operations runbook.

If several services contain a hard-coded endpoint, the migration is a good reason to move it into central configuration. This makes future routing changes easier and separates production, staging and fallback settings.

A controlled enterprise migration

A practical sequence is:

1. Find every reference to the old domain in source code, CI/CD, secrets, proxies and documentation.
2. Separate OAuth and inference API settings instead of storing them in one variable.
3. Permit the new domain in staging network policies.
4. Test token retrieval, the model list and a basic request with non-sensitive data.
5. Compare error handling, latency, streaming and rate-limit behaviour.
6. Move a small share of traffic and observe application metrics.
7. Update the runbook before removing the dependency on the old address.

The old URL remains available, but the source does not state an exact retirement date. This makes an emergency switch unnecessary while giving teams time to migrate before a hard deadline is announced.

What the endpoint change does not prove

A unified address does not by itself change model quality, pricing, limits or data-processing terms. Those parameters must be checked in the current documentation and contract. Models also do not become behaviourally identical merely because they share one API endpoint.

Teams should keep the model identifier separate from the base URL, pin or record SDK versions and maintain a regression evaluation set. Sensitive business workflows need output validation, action limits and human approval wherever an incorrect response could affect a customer or operation. Practical controls for tools, permissions and audit are covered in secure AI-agent architecture.

Practical B2B conclusion

This GigaChat API update is an infrastructure lifecycle change rather than a new product launch. Its practical value is that an IT team can migrate deliberately before the legacy endpoint is retired. The priorities are to separate authentication and model endpoints, validate network policies, remove hard-coded values and confirm application behaviour with staged traffic.

Source: the official GigaChat API documentation updated on 17 July 2026.