Skip to content

Email Verification Trust Declaration Required

URI: https://docs.ankatech.co/errors/federation-email-verification-trust-required
HTTP Status: 409 Conflict

When you see this

Enabling an OIDC identity provider was refused because no email-verification trust posture has ever been declared for it. An undeclared posture resolves to "not trusted" at the login seam, and an untrusted OIDC provider refuses every first-time login outright — so the provider would be enabled and able to onboard nobody.

Common Causes

  • The provider was declared without stating whether this deployment trusts the email addresses it asserts.
  • The declaration was never made because it is only reachable from the provider's own configuration, not from the enable action.

Response Example

{
  "type": "https://docs.ankatech.co/errors/federation-email-verification-trust-required",
  "title": "Email Verification Trust Declaration Required",
  "status": 409,
  "detail": "No email-verification trust posture has been declared for this identity provider, so it could not admit any first-time federated login. Declare whether this deployment trusts the provider's email addresses before enabling it.",
  "instance": "/api/v3/admin/platform/idp/3f2504e0-4f89-11d3-9a0c-0305e82c3301/enable",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000",
    "prerequisite": "EMAIL_VERIFICATION_TRUST_REQUIRED"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. extensions.prerequisite is the machine-readable form of the missing precondition.

This is a sibling of the verified-domain prerequisite, not a duplicate of it: both are preconditions on the deployment's own state and both answer 409, but they name different remedies. An explicit "not trusted" declaration is a valid configuration and is not refused here — only the absence of any declaration is. The remedy named is on the platform side, deliberately: the provider is behaving correctly and has nothing to change.

How to Resolve

  1. Open the provider's configuration and declare its email-verification trust — whether this deployment accepts the email addresses it asserts.
  2. Choosing "not trusted" is a legitimate answer for a provider that serves only identities already bound to a subject; it satisfies this precondition.
  3. Re-issue the enable request.

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