Prove Verified Users℠ SDK Guide
Learn more about the details of the server-side SDK.
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
ormobile
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()
, andComplete()
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, orpending
if the possession check needs to complete first. -
Possession Result: either
success
if the possession check was successful,failed
if it failed, orpending
if the possession check needs to complete first. -
Verify Result: either
success
if the verification was successful,failed
if it failed, orpending
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, orpending
if the possession check needs to complete first. -
Possession Result: either
success
if the possession check was successful,failed
if it failed, orpending
if the possession check needs to complete first. -
Verify Result: either
success
if the verification was successful,failed
if it failed, orpending
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.
Was this page helpful?