API-ключи
Как устроены ключи для ваших приложений: выдача, владельцы, привязка к системам/агентам и применение policy rules.
Кому подходит
- Разработчикам — подключение сервисов к моделям через один адрес.
- Администраторам — выдача ключей и управление доступом через policy rules.
- Финансам и ИБ — контроль расходов и владельца каждого ключа.
Зачем нужны ключи
Приложения не используют пароль от личного кабинета. Вместо этого им выдаётся API-ключ:
- идентифицирует вашу организацию;
- привязан к email владельца для учёта.
- может быть привязан к системе/агенту для наследования политик.
Ключ передаётся в заголовке при запросах к API моделей:
Authorization: Bearer sk-…Поля ключа
| Поле | Описание |
|---|---|
alias | Понятное имя (например, staging-key) |
ownerEmail | Ответственный сотрудник |
systemId | Опциональная привязка к информационной системе или агенту |
status | active или revoked |
Ограничения по моделям, бюджетам, контенту и RPM/TPM для ключа задаются не в полях ключа, а через Policy Rules на уровне api_key, system, member, virtual_group и organization.
Создание и хранение
Ключ создаётся в личном кабинете (раздел API-ключи) или через API платформы. Секретная строка показывается один раз при создании — сохраните её сразу; повторно она не отображается.
В кабинете и API всегда доступны метаданные: алиас, статус, владелец, привязка к системе (если есть).
Отзыв ключа
Если ключ скомпрометирован или больше не нужен, отзовите его в кабинете или через API. Статус станет revoked, секрет перестанет приниматься API моделей. Отзыв необратим — для нового доступа создайте ключ с другим алиасом. См. инструкцию.
Кто может управлять ключами
Создавать ключи могут владелец и администратор организации.
Пример создания через API
TOKEN="<сессионный-token>"
ORG_ID="<id-организации>"
curl -s -X POST "https://api.example.com/api/organizations/$ORG_ID/api-keys" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"alias": "my-service"
}'Ответ — объект ключа с метаданными (см. справочник API).