Ключ передаётся заголовком. Других способов нет: ни query-параметра, ни куки — ключ в URL попадает в логи прокси и в историю браузера.
curl https://zerno.one/api/v1/models \
-H "Authorization: Bearer $ZERNO_API_KEY"Ключ начинается с if-. В кабинете виден только префикс: полный ключ показывается один раз при выпуске и не восстанавливается. Потеряли — выпустите новый и отзовите старый.
Ключей можно выпустить сколько угодно, и это дешевле, чем разбираться потом. У каждого своя строка в логе активности и свои лимиты, поэтому всплеск расхода видно сразу и понятно, чей он.
| Что | Зачем |
|---|---|
| X-Request-Id (заголовок) | Ваш идентификатор запроса. Возвращается в ответе и проходит в лог — с ним разбирательство занимает минуты. |
| user (поле тела) | Идентификатор вашего пользователя: расход раскладывается по нему в кабинете. |
Ключ бывает двух родов. Обычный ходит в модели. Ключ выпуска (kind=provisioning) наоборот: он управляет ключами через /v1/keys и в модели не ходит вовсе. Разделение нужно ровно затем, чтобы утёкший рабочий ключ не мог напечатать себе новые — тогда отзыв одного ключа решает проблему, а не начинает погоню.
# выпустить ключ клиенту прямо из своего бэкенда
curl https://zerno.one/api/v1/keys \
-H "Authorization: Bearer $ZERNO_PROVISIONING_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "клиент 42",
"rpm_limit": 60,
"concurrency_limit": 4,
"daily_spend_limit_usd": "5",
"allowed_models": ["openai/gpt-4o-mini"]
}'Ответ содержит поле key — единственный раз, когда ключ виден. Дальше доступны GET /v1/keys, PATCH /v1/keys/{id} (правка лимитов) и DELETE /v1/keys/{id} (отзыв).
Отзыв действует сразу: следующий запрос с этим ключом получает 401. Уже начатые стриминговые ответы дописываются до конца — обрывать их посреди токена бессмысленно, платить за них всё равно придётся.