Skip to content

Trusted Issuer Not Found

URI: https://docs.ankatech.co/errors/trusted-issuer-not-found
HTTP Status: 404 Not Found

When you see this

No trusted-issuer declaration with that identifier is reachable from the tenant the request is scoped to, for the route you called.

This is also the answer when the identifier belongs to another tenant. The two responses are byte-identical on purpose: answering 403 for a row that exists and 404 for one that does not would turn the endpoint into an existence oracle that enumerates which authorization servers other customers trust, one probe at a time.

Which declarations are reachable depends on the route, and the two rules differ. The tenant-plane issuer registry routes — /api/v3/admin/tenants/{tenantId}/workload-identity/issuers/... — reach the tenant's own declarations only, because they are the routes that edit and withdraw a declaration, and a deployment-wide declaration is not a tenant's to edit. The binding routes under /api/v3/admin/tenants/{tenantId}/workload-identity/actors/{actorId}/issuer-bindings reach more: a binding may name any issuer the tenant trusts, which is its own declarations plus every issuer the deployment declares. GET /api/v3/admin/tenants/{tenantId}/workload-identity/bindable-issuers returns exactly that set, and an identifier taken from it will not produce this error.

Common Causes

  • The issuer identifier is mistyped, or belongs to a declaration that was already withdrawn.
  • The identifier belongs to a different tenant.
  • A registry route was called with a deployment-wide declaration's identifier. Read it, and read the issuers it trusts, from the tenant plane; edit and withdraw it from the deployment plane. On a binding route the same identifier is accepted.
  • The declaration was withdrawn between reading the list and issuing this request.

Response Example

{
  "type": "https://docs.ankatech.co/errors/trusted-issuer-not-found",
  "title": "Trusted Issuer Not Found",
  "status": 404,
  "detail": "No trusted issuer 9e2f77a1-3c04-42db-8f5b-1a6d0e93bb41 exists here.",
  "instance": "/api/v3/admin/tenants/3f9a1b62-5d47-4c8e-b0a2-91d7e4f60cc5/workload-identity/issuers/9e2f77a1-3c04-42db-8f5b-1a6d0e93bb41",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Take the identifier from the list the route you are calling actually accepts, rather than from an earlier copy: GET /api/v3/admin/tenants/{tenantId}/workload-identity/issuers for a registry call, and GET /api/v3/admin/tenants/{tenantId}/workload-identity/bindable-issuers for a binding, which additionally returns every issuer the deployment declares.
  2. If you are calling a registry route with a deployment-wide declaration's identifier, call the deployment plane instead — editing and withdrawing that declaration belongs to the operator who declared it. Do not declare it a second time on the tenant; a binding may name the existing deployment-wide row as it stands.
  3. Confirm the tenant in the path is the tenant that holds the declaration, or that inherits it.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.