Сохраните свой первый credential

Создайте личный default-credential, прочитайте его обратно маскированным и наблюдайте, как переключается credential-status.

Основной путь записи сервиса: сохранить ключ, убедиться, что он везде маскирован, и увидеть, как платформа признаёт его тем, на чём будут работать ваши переводы.

Цель

Закончить с активным default личным credential для одного провайдера и credential-status, называющим user эффективным источником.

Предварительные условия

• Код провайдера и его обязательные секретные поля — из сценария 01.
• $CREDS_BASE, $TOKEN.

Шаги

1. Проверьте статус до

Вызовите GET /v1/providers/{code}/credential-status. Ожидаемый 200 с "user_credentials_configured": false — пока ничего не настроено.

2. Создайте credential

Вызовите POST /v1/credentials:

curl -s -X POST "$CREDS_BASE/v1/credentials" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{
    "provider_code": "'$CODE'",
    "name": "My first key",
    "credentials": {"api_key": "sk-live-0123456789abcdef"},
    "make_default": true
  }'

Ожидаемый 201: запись с owner_type: "user", status: "active", is_default: true, version: 1 — и masked_credentials вместо вашего секрета (в стиле sk-***cdef). Сохраните id.

3. Прочитайте обратно — всё ещё маска

import httpx

headers = {"Authorization": f"Bearer {TOKEN}"}
record = httpx.get(f"{CREDS_BASE}/v1/credentials/{cred_id}", headers=headers).json()

assert record["masked_credentials"]["api_key"] != "sk-live-0123456789abcdef"
assert "credentials" not in record          # the plaintext field simply does not exist here

Ожидаемо: ни один ответ пользовательской плоскости никогда не несёт секрет. Списочное представление (GET /v1/credentials) показывает ту же запись с той же маской.

4. Проверьте статус после

Повторите шаг 1. Ожидаемо: "user_credentials_configured": true и "effective_credential_source": "user" — resolve теперь отдал бы ваш ключ.

Проверено тестом test_s02_store_your_first_credential.