What's the authoritative way to determine if an enterprise connection (esp. Azure AD/waad) is actually configured and usable via the Management API?

Get Help
,
1

We use GET /api/v2/connections to check the status of enterprise SSO connections (SAML/OIDC/Okta/Azure AD) created via the Self-Service SSO Profile flow. We’ve observed that the top-level enabled field on the connection object doesn’t reliably reflect whether the connection is actually working for waad (Azure AD/Entra) connections — it can report enabled: false even when the connection is live and users are authenticating through it.

As a workaround, we currently infer “configured” by checking whether options.domain_aliases (or similar domain fields) are set alongside a non-null options object. This is a heuristic, not a verified check.

Questions:

  1. Is enabled on the connection object expected to reliably reflect operational status for enterprise/waad connections, or is it scoped to something else (e.g. tenant-wide default vs. per-client assignment)?
  2. Given the recent deprecation of enabled_clients on GET/PATCH /connections (EOL July 13, 2026) in favor of GET /connections/{id}/clients, is there a new recommended field or endpoint combination to determine “is this connection actually usable by at least one application” without inferring from domain aliases?
  3. Is there a supported way to verify a connection is fully configured (e.g. a test-connection or health endpoint), rather than inferring from metadata presence?
3

Hi @ext.ramachandra.u.r

Welcome to the Auth0 Community!

On the Auth0 Connection object, the top-level enabled field does not reflect whether a connection is functionally active, nor does it mean it is globally enabled for the tenant.

The enabled tag was designed to toggle the connection state internally (for example, allowing or disallowing Auth0 to load the connection configurations into memory during authorization requests). For enterprise connections like waad (Azure AD/Entra), a connection can easily show enabled: false at the top level while still successfully routing authentication traffic if it has been mapped directly to specific clients (applications).

Because the enabled field’s operational meaning is highly context-dependent and often out of sync with actual client usage, relying on it to verify whether a connection is “live” or “ready to use” is not recommended.

With the End-of-Life of the enabled_clients field on the main connection endpoints (which took effect on July 13, 2026), you should no longer parse client assignments from the GET /api/v2/connections payload.

To determine if a connection is actually usable by at least one application, the recommended approach is to call the dedicated sub-endpoint:

  • Endpoint: GET /api/v2/connections/{id}/clients

This returns an array of client objects enabled for this specific connection. If the returned array has a length of 1 or more, the connection is actively mapped and usable by an application.

Also, there is no dedicated Management API endpoint (e.g., POST /api/v2/connections/{id}/test or similar) to programmatically check if an enterprise connection is fully configured and functional. This is an intentional design boundary in the OAuth2/SAML specifications. Since Auth0 acts as the Service Provider (SP), it cannot independently verify that an external Identity Provider (like Azure AD or Okta) is fully configured, reachable, or validating signatures without executing a live cryptographic handshake (which requires user browser redirection).

To programmatically confirm if a newly configured waad or SAML connection is operational, implement this workflow:

  1. Create a dedicated, non-production “Connection Verifier” Application (Client ID) in your tenant.

  2. Use the modern POST /api/v2/connections/{id}/clients endpoint to enable the newly created enterprise connection only for your Test Application.

  3. Have your integration programmatically initiate an /authorize request targeting the connection specifically:

    https://{your_auth0_domain}/authorize?
  client_id={YOUR_TEST_CLIENT_ID}&
  response_type=code&
  connection={YOUR_CONNECTION_NAME}&
  prompt=none&
  redirect_uri={YOUR_TEST_CALLBACK}

  4. If the challenge fails with login_required or consent_required, the connection routing is working perfectly (it successfully contacted the IdP, which asked for interaction).

    • If it fails with a different error (e.g., signature mismatch, domain error), query the Management API logs endpoint (GET /api/v2/logs) immediately with a query like: q=type:f AND connection:"{YOUR_CONNECTION_NAME}" to fetch the reason for the failure.

  5. Once verified, PATCH the connection to enable your production Client IDs.

Kind Regards,
Nik