Credential status

«What will I translate with?» — one call, four facts, zero secrets.

GET /v1/providers/{provider_code}/credential-status answers the question every translation UI asks before submitting a job: if I translate with this provider right now, whose key runs it?

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

• user_credentials_configured — you have an active default for this provider.
• organization_credentials_configured — your organization has one. Read the three states carefully: true (org default exists), false (the level exists for you and the provider, but no credential), null (your token has no org_id, or the provider does not admit the organization level at all — there is no level to speak of).
• platform_fallback_available — an active platform default exists and the provider's policy allows falling back to it.
• effective_credential_source — the level resolve would pick right now: user, organization, platform, or null (nothing configured — a resolve would fail with CREDENTIAL_NOT_CONFIGURED).

Why any role may call it

Unlike the organization credential inventory, status is deliberately open to every authenticated §5.1 role, including organization members without a manager role: it reports configuration facts, not records — no names, ids, masks, or timestamps of anyone's credentials. A member sees "the org has this covered" without seeing what exactly covers it.

Provider visibility follows the catalog rules (Vendors and Providers): a provider you cannot see is a 404 here too.