Prove provides server-side SDKs in the following languages: Java, TypeScript/JavaScript, and Go. If you use a different backend language, you can easily interact with the REST APIs.

Installation

Install the server-side SDK of your choice by running a command in your terminal, or by using a dependency management tool specific to your project.

We have code samples for how to interact with the API endpoints in many different languages. Browse the API Reference page and click your language from the top tabs.

OAuth for Authentication

In order to access the Prove API, you’ll need to provide your OAuth client ID and client secret. We recommend storing them.

You can load them from environment variables or another method:

Token Expiration

The OAuth token will expire after 60 minutes and you need to acquire another token.

Verify()

Add an endpoint to your server (example: POST /verify) so the frontend/client code can submit the flow type, phone number, first name, and last name. On the backend, you’ll start a Prove flow with a call to the Verify() function. This function takes these required parameters:

  • Flow Type: either desktop or mobile to describe which type of device the end user is starting their flow on.
  • Phone Number: phone number of the end user.

In sandbox, the phone number field tells the system which scenario you are testing. If you forget to pass in the phone number of a valid test user, then it will return an HTTP 400 (8007 - no test user found matching the phone number) error.

  • First Name: first name of the end user.
  • Last Name: last name of the end user.

Possession Timeouts

When flow type is desktop, Instant Link executes the possession check. When flow type is mobile, first Mobile Auth (if enabled) and then one-time password (OTP) as a fallback. The Instant Link session has a five minute timeout from when it’s sent via SMS to when the end user can click on the link successfully. The OTP session has a two minute timeout from when it’s sent via SMS to when the end user can enter in the OTP successfully.

  • Final Target URL: only required when Flow Type=desktop. It can be either a Prove provided URL or your own URL that instructs the end user to close their mobile browser.

Optionally, you can pass one of these parameters:

  • SMS Message: a field to customize the message body sent in the Instant Link (flowType=desktop) or OTP (on mobile) SMS message. Otherwise, you can use Prove defaults.
  • Client Customer ID: a client-generated unique ID for a specific customer. You can link calls related to the same customer, across different requests or sessions. The client defines the format of this ID.
  • Client Request ID: a client-generated unique ID for a specific session. You can identify specific requests using this field. You determine the format of this ID.

Here is an example:

The function returns the following fields:

  • Auth Token: send this to your client side code to pass into the Authenticate() function - it’s a short lived JSON Web Token (JWT) tied to the current flow and used to facilitate the possession checks.

  • Correlation ID: save this in your current session, you will pass it in to each of the Validate(), Challenge(), and Complete() function calls of the same flow.

The correlation ID allows Prove to tie together different system calls for the same Prove flow. It also aids in troubleshooting. The session will expire in 15 minutes from when the correlation ID returns from the Start() call.

  • Success: true if the challenge succeeded and user info returned, false if it failed, or pending if the possession check needs to complete first.

  • Possession Result: either success if the possession check was successful, failed if it failed, or pending if the possession check needs to complete first.

  • Verify Result: either success if the verification was successful, failed if it failed, or pending if the verification check needs to complete first.

If using possession, then the response will contain the authToken, returned to the frontend.

VerifyStatus()

Once the possession check is complete, your backend calls VerifyStatus() to get the final result in the success field.

This function is the final call in the flow that verifies the user information.

This function takes this required parameter:

  • Correlation ID: this is the ID returned by the Verify() function. It will validate against this RegEx: ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$.

Here is an example:

The function returns the following fields:

  • Success: true if the challenge succeeded and user info returned, false if it failed, or pending if the possession check needs to complete first.

  • Possession Result: either success if the possession check was successful, failed if it failed, or pending if the possession check needs to complete first.

  • Verify Result: either success if the verification was successful, failed if it failed, or pending if the verification check needs to complete first.

You can then respond to the frontend with the results of the user verification.

SDK Updates

You will find the server SDKs on GitHub. Once you create a free GitHub account, you can Watch any of the projects to receive notifications when there are updates.