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.

Prove publishes server-side SDKs for Go, Java, .NET, TypeScript, and JavaScript. Other stacks use the same HTTP operations documented under Reference (for example POST /v3/start, POST /v3/validate, POST /v3/challenge, POST /v3/complete).
Token expiration — Access tokens expire after 60 minutes. Refresh or obtain a new token before long-running jobs.

​
Follow the Next field

Each SDK call returns a Next map. Do not hard-code the full sequence after Start: read Next and call the indicated operation until the flow ends. The sections below describe parameters and return fields for each call.

​
Start()

Expose a server endpoint (for example POST /initiate) so your front end can send flow type, phone number, and any challenge inputs. On the server, call Start() with at least:
  • Flow type — desktop or mobile for the device class starting the session.
Possession channels — On desktop, possession typically uses Instant Link; on mobile, Mobile Auth then OTP when applicable. Instant Link and OTP sessions have short SMS-side timeouts; for behavior and UX, see Prove Pre-Fill flow.
  • Final target URL — Required when flowType=desktop: URL the customer reaches after tapping the Instant Link (max 128 characters).
Optional on Start():
  • ssn — Full SSN or last four digits.
  • dob — YYYY-MM-DD, YYYY-MM, or MM-DD.
  • allowOTPRetry — true to allow up to three OTP retries (defaults to false). Requires matching client SDK handling.
Returns
  • Auth token — Short-lived JWT for the current flow; passed to the client Authenticate() method for possession checks.
  • Correlation ID — Identifier for this flow; include on future calls for the same session. Correlation context expires 15 minutes after Start() returns. Useful for troubleshooting.
  • Next — Next operation to invoke.
In Sandbox, the phone number must identify a configured test user. Omitting it or using a non-test number can yield no test user found matching the phone number.

​
Validate()

Validates possession after the client signals completion. Parameter: correlation ID from Start() (often from a server route such as POST /verify). Returns
  • success — true if mobile validation succeeded; otherwise false.
  • Phone number — Validated E.164 value when present.
  • Next — Next operation to invoke.
  • challengeMissing — When true, collect SSN or DOB (or call Challenge() if those values were already supplied on Start() per your flow).
Use challengeMissing and Next to decide whether to return a challenge UI to the browser or invoke Challenge() on the server.

​
Challenge()

When Validate() includes v3-challenge in Next, call Challenge() to retrieve attributes for the phone number plus challenge. Pre-Fill uses this path. Prove Identity may move to v3-complete in Next after a successful Validate() instead of v3-challenge. Parameters
  • Correlation ID — From Start() (required).
If Validate() set challengeMissing=true, include one of:
  • ssn
  • dob — Same formats as on Start().
Returns
  • success — Whether customer data was returned.
  • individual — Attribute map (up to three addresses possible).
  • Next — Next operation.
When success is true, return individual to the client for pre-fill.

​
Complete()

After the customer confirms or edits pre-filled data, submit the payload to your server and call Complete() — the final verification step. Parameters
  • Correlation ID — From Start(); must match UUID pattern ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$.
  • individual — The customer data map to verify.
Returns
  • success — Whether verification succeeded.
  • Next — Typically Done when the flow is finished.
Respond to the client with the verification outcome.