Skip to content

Federated Email Already Owned

URI: https://docs.ankatech.co/errors/federated-email-conflict
HTTP Status: 409 Conflict

When you see this

A federated identity signed in for the first time and the email address its provider asserted is already owned by another account in the same tenant. The refusal is unconditional and writes nothing: the authoritative federation key is the pair of identity provider and external subject, and an email address is never used to re-link an existing account.

Common Causes

  • The address already belongs to a local account in the tenant — typically the break-glass administrator, which is never silently converted into a federated account.
  • The address already belongs to a different federated subject in the tenant.
  • The identity provider changed the address it asserts for a subject onto one another account already holds.

Response Example

{
  "type": "https://docs.ankatech.co/errors/federated-email-conflict",
  "title": "Federated Email Already Owned",
  "status": 409,
  "detail": "This email is already owned by another account in the tenant; federated provisioning is refused.",
  "instance": "/api/v3/admin/s2s/auth/idp/provision",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

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

The body is identical whichever kind of account owns the address, down to Content-Length, and it names neither the submitted address nor the tenant. A caller who controls an identity provider can drive both cases, so telling them apart would let them enumerate which kind of account owns an address. The browser-visible outcome of a federated login is likewise collapsed onto the shared "access not configured" result for the same reason — this dedicated type exists so the operator can separate the cause in the audit trail, not so the visitor can.

How to Resolve

  1. Find the existing account holding that address in the tenant, using an authenticated administrative read.
  2. If the address belongs to a local account that should become federated, retire or re-address that account deliberately rather than letting a login claim it.
  3. If the address belongs to a different federated subject, correct the claim at the identity provider so each subject asserts its own address.

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