Skip to main content

Documentation Index

Fetch the complete documentation index at: https://developer.prove.com/llms.txt

Use this file to discover all available pages before exploring further.

Use this guide when you already know you want Prove Unified Authentication with a server-side SDK (Go, Java, .NET, TypeScript, or JavaScript). When you finish, your backend can start a Unify session, poll for the final possession result, and—if you use customer-supplied possession—bind the phone to the Prove Key. For conceptual background (flows, possession variants, Prove Key), see Unified Authentication overview. Prerequisites
HTTP endpoints for this how-to

​
Unify()

Add an endpoint to your server such as POST /unify so the front end can submit the possession type and phone number. On the back end, start a Prove Unified Authentication flow with a call to the Unify() function. This function takes these required parameters:
  • Possession Type: specify mobile, desktop, or none for customer-supplied possession to describe which type of device the end user is starting their flow on.
  • Phone Number: phone number of the end user.
Timeouts (operational)desktop uses Instant Link (three minutes from SMS send to link use). mobile tries the Prove Key first, then can fall back to OTP (two minutes from SMS send to code entry). For how possession variants fit together, see Unified Authentication overview.
Everything else — Optional fields (for example finalTargetUrl when possessionType=desktop, checkReputation, identifiers, deviceId, rebind, allowOTPRetry) are documented on POST /v3/unify. Set them according to your product rules. Use these fields from the Unify() response
  • authToken — When your front end uses a Prove Unify client SDK, return this to the client for Authenticate() (prove-led mobile/desktop flows and customer-supplied flows that use the client SDK). Short-lived JWT scoped to this session; expires after about 15 minutes (see POST /v3/unify for session timing).
  • Correlation ID — Persist on the server and pass into UnifyStatus() for the same flow. Expires 15 minutes after this response.
  • Success — On this first call, expect pending while possession runs.
For every response field, JWT behavior, and errors, see POST /v3/unify.
Phone number vs Prove Key — If you call Unify() with a phone number that does not match the number bound to the user’s Prove Key, UnifyStatus() may return success=false. Start a new flow with rebind=true on POST /v3/unify to force a full possession check and rebind the key when appropriate. See Prove Key validity and expiration.

​
UnifyStatus()

After the client finishes possession, call UnifyStatus() with the correlation ID from Unify() to read the final outcome (including success). This maps to POST /v3/unify-status. Required
  • Correlation ID — UUID returned by Unify(). Format: ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$.
For the full response schema and status semantics, see POST /v3/unify-status. You can then respond to the front end with the results of the authentication.

​
UnifyBind()

Prove-led possession (mobile or desktop) does not use UnifyBind()—Prove handles possession through the client SDK. Use bind only for customer-supplied possession (possessionType=none). Customer-supplied possession only: call UnifyBind() after UnifyStatus() returns success=possession_required, and only if your customer-supplied possession check has passed. This binds the phone to the Prove Key. This maps to POST /v3/unify-bind. Required
  • Correlation ID — From the Unify() response.
  • Phone number — To bind to the Prove Key.
Optional fields (for example clientRequestId) are listed on POST /v3/unify-bind.
The function returns the following fields:
  • Success: true if the binding succeeded, false if it failed.
  • Phone Number: the phone number bound to the Prove Key.
  • clientHumanId: a client-generated unique ID to identify a specific customer across business lines.
  • clientRequestId: a client-generated unique ID for a specific session.
  • deviceId: the unique identifier for the Prove Key on the device.
For all response fields and errors, see POST /v3/unify-bind. Interpret evaluation using the Global Fraud Policy when present.