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

# Configure your service provider

> The two values that register an SP, what activates immediately, and what a person actually experiences.

## Endpoints

| Endpoint         | URL                                          | Notes                                                                                        |
| ---------------- | -------------------------------------------- | -------------------------------------------------------------------------------------------- |
| IdP metadata     | `https://idp.facesign.dev/api/saml/metadata` | Import this. Carries entityID, X.509 signing certificate, both SSO bindings.                 |
| Single Sign-On   | `https://idp.facesign.dev/api/saml/sso`      | HTTP-Redirect and HTTP-POST bindings.                                                        |
| Service health   | `https://idp.facesign.dev/api/health`        | Checks metadata generation and signing key/certificate pairing. Not an end-to-end flow test. |
| Loopback sandbox | `https://idp.facesign.dev/test-sp`           | FaceSign's own demo SP. A full round-trip without registering anything.                      |

## Register

Two values, both from your side:

<ParamField path="entityID" type="string" required>
  Your service provider's unique identifier, exactly as your SP sends it in the AuthnRequest
  `<Issuer>`. Case-sensitive, matched as an exact string.
</ParamField>

<ParamField path="ACS URL" type="string" required>
  Your Assertion Consumer Service URL — where FaceSign POSTs the signed response.
  HTTP-POST binding, `https` only.
</ParamField>

Register in the [partner portal](https://idp.facesign.dev/portal), or by email to
[partnerships@facesign.ai](mailto:partnerships@facesign.ai?subject=FaceSign%20SAML%20IdP%20—%20SP%20registration).

<Note>
  Sandbox service providers activate immediately. **Production activation is reviewed by FaceSign
  against a verified domain** — it is not self-service. Plan for a review step.
</Note>

## Request signing

The metadata declares `WantAuthnRequestsSigned="false"`. Signed AuthnRequests are not supported in this release —
the IdP rejects them. Send unsigned requests for now.

If your service provider signs by default and cannot be configured otherwise, raise it before
you begin integration; it changes the scope of the work on our side.

## What the person actually experiences

Worth being explicit, because the test harness can mislead you here. In production a person
never sees a SAML form, a NameID field, or any XML. They:

1. Attempt some protected action in your application.
2. Get redirected to FaceSign by your service provider.
3. Have a short conversation with an avatar, with their camera on.
4. Get returned to your application automatically.

Everything else — the loopback launcher, the NameID field in a test form, the ACS debug view —
is developer tooling. Do not model your production experience on it.

## Related

<CardGroup cols={2}>
  <Card title="SAML request contract" icon="file-code" href="/saml-request-contract">
    What FaceSign accepts and what it returns.
  </Card>

  <Card title="Validate responses" icon="shield-check" href="/validate-responses">
    Everything your SP must check before trusting a response.
  </Card>
</CardGroup>