Как отправить первый запрос в GigaChat API через новый адрес api.giga.chat

curl -X POST 'https://api.giga.chat/v1/chat/completions' \
+ -H 'Accept: application/json' \
+ -H 'Content-Type: application/json' \
+ -H "Authorization: Bearer $GIGACHAT_ACCESS_TOKEN" \
+ -d '{
+   "model":"GigaChat",
+   "messages":[
+     {"role":"system","content":"Отвечай кратко. Если данных нет — так и скажи."},
+     {"role":"user","content":"Верни три проверки для карточки товара."}
+   ],
+   "stream":false,
+   "max_tokens":500
+ }'

• messages сохраняет порядок ролей system/user/assistant; сервер приложения формирует историю, а не надеется на память отдельного REST-вызова.
• Полезный текст извлекают из choices, но перед этим проверяют HTTP-код, наличие массива и причину завершения.
• usage нужен для контроля токенов и расходов; сохраняйте агрегаты по сценарию, не полный пользовательский текст.
• Имя модели сверяйте через /v1/models, потому что доступный набор зависит от проекта и меняется.

Порядок действий

1. Получите и закэшируйте access token.
2. Вызовите GET /v1/models и выберите доступную модель, подходящую сценарию.
3. Отправьте короткий системный контракт и пользовательскую задачу.
4. Проверьте HTTP-статус, choices, finish reason и usage.
5. Добавьте ограниченные повторы только для временных ошибок и 429.

Как проверить результат

Попросите вернуть ровно три строки и проверьте количество программно. Затем запросите несуществующий внутренний факт: системная инструкция должна привести к честному отсутствию данных. Неверное имя модели должно обрабатываться как ошибка, а не как пустой ответ.

Ограничения

Пример имени модели иллюстративный — рабочее значение берите из /v1/models. Новый домен указан официальной документацией на 17 июля 2026 года. Точные квоты и коммерческие условия зависят от проекта.

Чего не делать

• Не фиксируйте имя preview-модели без проверки списка.
• Не считайте HTTP 200 достаточным без проверки choices.
• Не пересылайте всю историю чата без ограничения размера.

Частые вопросы