Статус credentials

«Чим я перекладатиму?» — один виклик, чотири факти, нуль секретів.

GET /v1/providers/{provider_code}/credential-status відповідає на питання, яке кожен UI перекладу ставить перед відправленням задачі: якщо я зараз перекладаю цим провайдером — чий ключ це виконає?

{
  "provider_code": "deepl_api",
  "user_credentials_configured": true,
  "organization_credentials_configured": null,
  "platform_fallback_available": true,
  "effective_credential_source": "user"
}

• user_credentials_configured — ви маєте активний default для цього провайдера.
• organization_credentials_configured — його має ваша організація. Уважно читайте три стани: true (org-default існує), false (рівень для вас і цього провайдера існує, але credential немає), null (ваш токен без org_id, або провайдер взагалі не допускає рівень організації — рівня просто немає).
• platform_fallback_available — активний platform-default існує, і політика провайдера дозволяє на нього провалитися.
• effective_credential_source — рівень, який resolve вибрав би просто зараз: user, organization, platform або null (нічого не налаштовано — resolve впав би з CREDENTIAL_NOT_CONFIGURED).

Чому це може викликати будь-яка роль

На відміну від інвентаря credentials організації, статус навмисно відкритий кожній автентифікованій ролі §5.1, включно з учасниками організації без менеджерської ролі: він звітує факти конфігурації, а не записи — жодних імен, id, масок чи часових міток чиїхось credentials. member бачить «в організації це покрито», не бачачи, що саме це покриває.

Видимість провайдерів іде за правилами каталогу (Vendors and Providers): провайдер, якого ви не бачите, і тут відповідає 404.