Как создать API-ключ Open WebUI и проверить доступ к моделям

Как получить ключ, не сломав старую интеграцию?

1. Сначала спросите, используется ли ключ этого аккаунта другим скриптом. У одного аккаунта Open WebUI только один действительный API-ключ: кнопка Create new key заменяет его и сразу останавливает старую интеграцию. Если нужна независимая автоматизация, используйте отдельный аккаунт с минимально необходимыми правами; не создавайте новый ключ поверх рабочего. s1
2. В Open WebUI откройте значок профиля → Settings → Account, разверните Secrets кнопкой Show. Если ключ уже есть, не нажимайте Create new key ради просмотра: скопируйте существующий только если вы отвечаете за его использование. Если ключа нет, нажмите Create new secret key, затем скопируйте значение. Не публикуйте его и не вставляйте в адресную строку или чат. s1
3. Если раздела API Keys совсем нет, администратору надо включить API Keys в настройках Authentication; пользователю без роли администратора ещё требуется разрешение API Keys в группе или общих правах. Сообщение API key creation is not allowed — повод проверить эти настройки, а не забирать чужой ключ. s1 s3

Как проверить доступ только к списку моделей?

Откройте Bash на Linux на том же компьютере, где доступен Open WebUI. Введите read -rs -p 'Ключ Open WebUI: ' OWUI_KEY; printf '\n', вставьте скопированный ключ и нажмите Enter. Ввод не показывается на экране и сам ключ не записывается в текст команды. Затем выполните curl -sS -i -H "Authorization: Bearer ${OWUI_KEY}" http://localhost:3000/api/models; после проверки — unset OWUI_KEY. Для другого адреса замените только http://localhost:3000 на свой адрес Open WebUI; не передавайте секрет по обычному HTTP через внешнюю сеть. s1 s2

Ожидаемая проверка: ответ HTTP 200 и JSON со списком моделей; если список пуст, это ещё не доказательство ошибки ключа — проверьте подключение модели отдельно. Пример учебной задачи без действительного секрета: программа читает доступные имена моделей, вы сверяете одно из них со списком в интерфейсе. Генерацию ответа модели этот запрос не проверяет и офлайн-режим не подтверждает. s2

Что делать при отказе и как ограничить риск?

• HTTP 401: проверьте, не скопировали ли устаревший ключ после замены, и передаётся ли он как Authorization: Bearer .... Не печатайте ключ в диагностический лог. s1 s4
• HTTP 403: проверьте глобальный переключатель, разрешение пользователя и, если администратор включил ограничение маршрутов, наличие /api/models в общем разрешённом списке. Ограничение маршрутов действует на весь экземпляр, а не на один ключ. s1 s4
• Ключ больше не нужен или раскрыт: удалите его или замените в настройках аккаунта. Существующий ключ не имеет автоматического срока действия; замена и удаление отключают старое значение. Не выдавайте ключ администратора обычному скрипту: он наследует права владельца аккаунта. s1

Начните с настройки самой модели в Open WebUI, если в проверке ещё нечего перечислять. Не путайте список в API с ответом модели: успешный запуск проверяют отдельным учебным вопросом по выбранному локальному подключению. s2