What UnifyID gives you

Verified people, and the applications they trust. That is the whole of it.

One thing

UnifyID gives you verified people — someone signs in, and you receive claims about them that a human being approved, one by one, on a screen you do not control.

That is the list. If you are looking for something else on this site, it is probably not here yet, and these pages will say so rather than imply otherwise.

Verified people

The sign-in is ordinary OpenID Connect. Your application sends a person to UnifyID, UnifyID verifies them and shows them exactly what would be released, and if they approve you get an authorization code to exchange for tokens.

The discovery document is the contract. Read it rather than trusting a hostname you found somewhere:

Read the discovery document

curl -s "$UNIFYID_API/.well-known/openid-configuration"

Four lines of it decide how you write your client:

grant_types_supportedauthorization_code: The authorization code grant is the only grant. There is no implicit flow, no client credentials grant, and no refresh grant advertised.
code_challenge_methods_supportedS256: PKCE is required of every client, public or confidential, at authorize and again at token, and S256 is the only method offered. Do not send plain, and do not expect a client secret to stand in for it.
subject_types_supportedpairwise: The sub you receive is specific to your application. The same person signing into a second application of yours gets a different sub. Never use it as a global user id across products.
id_token_signing_alg_values_supportedRS256: ID tokens are RS256. Verify them against the JWKS at jwks_uri.

What this does not do

There is no claims API. Claims about a person reach you through an OAuth sign-in and nowhere else. There is no endpoint you can call with a client secret to look somebody up, and there will not be one described here until there is.
No refresh grant is advertised. grant_types_supported lists authorization_code and nothing else. Plan for the person coming back through the authorize endpoint.
A `sub` is not a person. It is a person *as seen by your client id*. Two of your applications will never agree on it.

Verified against API commit 234dba22 on 2026-10-18. The routes, scopes, checklist, events and limits on these pages are read from that export, not typed.