POST/api/sso/:tenantSlug/saml/acs

Assertion Consumer Service: receives the SAML response signed by the identity provider via form POST. Called exclusively by the identity provider, not by an API client.

The page “POST /api/sso/:tenantSlug/saml/acs — API Reference” covers the function identified by this URL. The existing summary is expanded with the actual workflow, prerequisites and known limitations. Zentor has no developer API-key system. The dashboard uses session JWTs with a 12-hour lifetime and refresh tokens lasting seven days; TOTP and SSO are optional. Widget embed tokens are shown in plaintext only once and are restricted to approved origins. `POST /api/sso/:tenantSlug/saml/acs` must be implemented as the specific operation documented on this page. The client should follow the declared method, path, authentication model, required fields and error responses rather than copying only the example payload. Zentor has no general developer API-key system; a route is either public or relies on the documented Widget token and origin validation. For `/api/sso/:tenantSlug/saml/acs`, evaluate the HTTP status together with the JSON body. Validation failures, missing resources, rejected origins, expired one-time values and server errors require different handling. A technically successful request confirms only this processing step; it does not automatically prove that an email was delivered, a payment completed or an identity provider finished an SSO flow. Use anonymised test values for `POST /api/sso/:tenantSlug/saml/acs`. Public examples must not contain real customer data, production-like UUIDs, session JWTs, Widget tokens or concrete historical timestamps. The known platform-wide limit is 2,000 requests per 15 minutes. No separate limit for this individual endpoint is proven, so clients still need to cap retries and avoid uncontrolled polling. Idempotency matters when retrying this route. A non-idempotent POST must not be sent again automatically after an ambiguous network interruption, because the original request may already have created a side effect. Logs should record status, error code and a safe request reference, but never passwords, reset tokens or other credentials. This is directly relevant to “POST /api/sso/:tenantSlug/saml/acs”. The source of truth for “POST /api/sso/:tenantSlug/saml/acs — API Reference” is the API registry under `app/frontend/src/content/api-reference/` together with the corresponding backend route and tests. A negative test or a similarity to another code path does not represent a complete live verification. The page has to state precisely whether a claim comes from schema, automated test or safely observed live behaviour.

302 redirect to <FRONTEND_URL>/login?sso_error=SSO_STATE_MISSING (example without a valid SAML response)