Managing Biometric Profiles: The User-Management API

The user-management API gives your application control of the profile lifecycle for the hosted-profile mode. All endpoints live under:

$BASE/oidc/v1/admin/users/biometric_profile/

Authentication. Use HTTP Basic with your OIDC client credentials: client_id as username and client_secret as password. The profiles you manage are exactly the profiles your logins use — the login_hint values are the same.

Operations. Every operation is a POST with a JSON body:

Endpoint	Body	Effect
…/status	{"login_hints": ["<id>", …]}	Report each profile's status without changing it.
…/info	{"login_hints": ["<id>", …]}	Like status, additionally returns the internal profile_id.
…/create	{"login_hint": "<id>", "portrait": "<base64>", "source": "eid"|"oid"|"selfie"}	Create (enroll) a profile from a trusted reference portrait.
…/delete	{"login_hints": ["<id>", …]}	Permanently delete the profile(s).
…/reset	{"login_hint": "<id>", "portrait": "<base64>", "source": …}	Convenience: delete + create in one call. Without a portrait, the call just deletes — the next login re-enrolls.

The source declares where the reference portrait came from: eid (read from an identity document's chip), oid (optical capture of a document), or selfie.

Example — Check, Then Create

curl -s -X POST "$BASE/oidc/v1/admin/users/biometric_profile/status" \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"login_hints": ["jane.doe@example.com"]}'
# → {"result":[{"status":"NOT_FOUND","login_hint":"jane.doe@example.com"}]}

curl -s -X POST "$BASE/oidc/v1/admin/users/biometric_profile/create" \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"login_hint": "jane.doe@example.com",
       "portrait": "<base64-encoded-image>",
       "source": "oid"}'
# → {"result":[{"status":"ACTIVE","login_hint":"jane.doe@example.com"}]}

Example — Offboard a User

curl -s -X POST "$BASE/oidc/v1/admin/users/biometric_profile/delete" \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"login_hints": ["jane.doe@example.com"]}'
# → {"result":[{"status":"DELETED","login_hint":"jane.doe@example.com"}]}

Each result entry carries a status — typically ACTIVE (profile exists / was created), NOT_FOUND, DELETED, RESET, or ERROR (with error_details).

Typical Lifecycle Patterns

• Pre-provisioning — create each user from a trusted portrait before their first login. Even the first login is then a 1:1 verification, with no trust on first use.
• Account recovery / re-enrollment — reset with a fresh portrait, for example after identity re-proofing at the helpdesk. Or reset/delete without a portrait; the user's next login then re-enrolls their live face.
• Offboarding and erasure — delete removes the biometric profile permanently. Use it for leavers and data-subject erasure requests.

Availability. create, status, and info work for every client. delete and reset require your account to run on a dedicated iProov service configuration, not the shared default. If you get an authorization error mentioning a shared configuration, contact iProov to have a dedicated one provisioned.