Схеми провайдерів

credential_schema і configuration_schema — будуйте з них форми, а 422 хай буде вашим валідатором.

Картка кожного провайдера несе дві JSON Schema (Draft 2020-12). Вони — контракт між каталогом і кожним credential, який ви зберігаєте:

• credential_schema — секретні поля. {"api_key": ...} для більшості провайдерів; пари ключів для AWS-стилю (access_key_id + secret_access_key); цілий вкладений об'єкт service-account для Google. Усе під нею шифрується at rest і повертається лише маскованим.
• configuration_schema — несекретні налаштування, збережені поруч із секретом: регіон, базовий URL, id моделі. Зберігаються й повертаються відкрито.

Будуйте форми, не хардкодьте

Схеми достатньо самоописові, щоб відрендерити форму: required перелічує обов'язкові поля, properties.*.title дає підписи, enum дає дропдауни (напр. вибір моделі в LLM-провайдерів), const фіксує дискримінатори. UI, що рендериться зі схеми, переживає кожне оновлення каталогу без релізу — саме так працює операторська панель.

import httpx

provider = httpx.get(
    f"{CREDS_BASE}/v1/providers/deepl_api",
    headers={"Authorization": f"Bearer {TOKEN}"},
).json()

schema = provider["credential_schema"]
print(schema["required"])            # ['api_key']
print(list(schema["properties"]))    # ['api_key']

Валідація відбувається на записі

POST /v1/credentials і кожна ротація валідують ваш об'єкт credentials проти credential_schema, а configuration — проти configuration_schema. Невідповідності відповідають 422 з окремим кодом на кожен об'єкт:

• CREDENTIAL_SCHEMA_VALIDATION_FAILED — хибний секретний об'єкт;
• CONFIGURATION_SCHEMA_VALIDATION_FAILED — хибна конфігурація.

error.details.errors несе вказівники на поля й повідомлення — але ніколи ваші надіслані значення, тож відповідь безпечно логувати. Невідомі поля теж падають: більшість схем ставить additionalProperties: false, і чого схема не дозволяє, того сховище не збереже. Розібраний приклад: сценарій cookbook 10.