> ## Documentation Index
> Fetch the complete documentation index at: https://docs.api.ignitehealth.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Access and testing

> Understand Ignite account linking and test SSO before production.

Ignite must confirm test identities and connection settings before sandbox testing.

After your IdP authenticates a user, Ignite checks the identity and the user's Ignite access. An employee record or employee identifier does not by itself grant SSO access.

## First and repeat sign-in

| Sign-in state | Behavior |
| - | - |
| First sign-in | Ignite looks for an existing account with the asserted email, then records a link from the `providerId` and OIDC `sub` or SAML NameID. A new account requires an eligible invitation. |
| Repeat sign-in | Ignite uses the recorded provider and subject link. |
| Existing account | The account needs Ignite membership or an eligible invitation. If several eligible invitations match the Ignite launch, Ignite attempts to accept the most recently created one. If acceptance fails, access is denied. |
| Ineligible access | Missing, expired, or wrong-tenant invitations do not grant access. Admin and superadmin accounts are rejected by this flow. |
| Incomplete profile | An authorized user who has not completed their employee profile goes to Ignite onboarding. |

An eligible invitation is pending, unexpired, and addressed to the email asserted at first sign-in. Your team requests invitations through [dev@ignitehealth.com](mailto:dev@ignitehealth.com). Ignite creates, resends, and revokes them.

## Verify the sandbox connection

Ignite supplies mapped fixture identities, the required account and invitation states, destinations, and reset instructions. Your team supplies IdP test identities. Together, test:

1. First sign-in, repeat sign-in, and reuse of the identity link.
2. Existing membership, one eligible invitation, no eligible invitation, and an incomplete profile.
3. Invalid or missing claims and IdP or Ignite service failures. Failed authentication must not grant access.

## Prepare production

After sandbox verification, Ignite provides separate production registration settings and confirms a pilot identity and launch URL. Register those values in your production IdP, run a sign-in test, and agree on contacts and credential or certificate ownership before activation.

## Troubleshooting sign-in

| What you see | What to check |
| - | - |
| The launch URL does not open sign-in | Confirm the exact environment and launch URL supplied for your connection. The `providerId` must match that URL. |
| Your IdP rejects the redirect or ACS URL | Compare its registered URL with the exact URL Ignite supplied for that environment. |
| OIDC sign-in fails after IdP authentication | Compare the registered redirect URI, client ID, client authentication method and secret, PKCE setting, and requested scopes with the values Ignite confirmed for this environment. |
| SAML response is rejected | Compare the ACS URL, IdP metadata and signing certificate, signature settings, and NameID format and source with the values Ignite confirmed for this environment. |
| IdP sign-in succeeds, but Ignite access is denied | Ask Ignite to check the user's account membership or invitation. A missing, expired, or wrong-tenant invitation does not grant access. |
| A new user cannot complete first sign-in | Confirm that the IdP supplies the agreed email claim or attribute and ask Ignite to check for an eligible invitation. |

For unresolved failures, email [dev@ignitehealth.com](mailto:dev@ignitehealth.com) with the environment, `providerId`, approximate time, and the step that failed. Do not include credentials or tokens.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.