Test identities

Sandbox only

Invented people with real records: four scenarios, ten per application, resettable.

What a test identity is

A test identity is a synthetic UnifyID person that a sandbox application's team can sign in as. It is exactly as real people are in production, only invented: a name, an adult date of birth, a nationality and a passport. A verified one signs in and userinfo answers from its records.

Its addresses use the domain test-identities.unifyid.invalid. .invalid never resolves, by RFC 6761, so no mail can be sent to a test identity by accident.

The four scenarios

Scenario	Outcome	What it is
verified	Signs in	A verified person with a passport, passed liveness and face match. Signs in; userinfo answers with their details.
failed	Refused	A person whose identity verification failed. Sign-in is refused and your app receives access_denied.
under_review	Refused	A person whose verification is still being reviewed. Sign-in is refused and your app receives access_denied.
restricted	Refused	A verified person whose account is restricted while a review is open. Sign-in is refused and your app receives access_denied.

Three of the four exist so that you build the refusal path. A refusal is not an error page — it is error=access_denied arriving at your registered redirect URI, and your callback has to handle it.

Creating, resetting, removing

A sandbox application may hold at most ten live test identities. You create, reset and remove them on the application's Test identities screen (/applications/<applicationId>/test-identities); every one of these is a session-bound developer route, done in the console.

Create a verified test identity (what the console sends)

POST /v1/developer/applications/{applicationId}/test-identities
content-type: application/json

{ "scenario": "verified" }

The screen lists them from GET /v1/developer/applications/{applicationId}/test-identities and removes one with DELETE …/test-identities/{testIdentityId}.

Reset one (what the console sends)

POST /v1/developer/applications/{applicationId}/test-identities/{testIdentityId}/reset

Reset ends the identity's sandbox consents and tokens and returns its records to the scenario. It is the way to see the first-time consent screen again: a returning person who already approved the application sees a short continue screen instead. See Revocation and webhooks for why you cannot simply ask for a narrower grant instead.

What this does not do

Names are invented, not anonymised. Nothing in a test identity describes a real person, and nothing about one should be carried into production fixtures as if it were.
Reset is not a sandbox wipe. It clears that one identity's consents and tokens. It does not touch your application's configuration, its credentials, or its other test identities.
Ten is the cap. Delete before you create when you hit it; there is no expansion request documented here.

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.