Verify API v4

This page provides an overview of Arkose Labs Verify API, specifically v4, the latest version. It also describes how to use the Verify API in your application.

Other pages that document the Verify API are:

Overview

The Verify API verifies a session for both Arkose Detect and Arkose Protect, the latter after the Enforcement Challenge (EC) process. For security reasons, it is always called for each session from your server-side code. Its parameters are your Arkose private key and the session token returned from the Client API], whether or not an EC was presented.

Verify's response indicates if the user was verified. It can be in a simple 1 or 0 format, or in a full JSON format. Your server-side code deals with handling and analyzing the response.

Scenario 1

A user tries to sign on to a website. No EC is presented, either because the site is running Arkose Detect or because Arkose Protect decides not to serve them an EC. You call the Verify API to validate the session token, with the verification response passed back to your server.

Scenario 2

A user tries to sign on to a website configured for Arkose Protect. Arkose Protect decides to serve them an EC. The user completes the challenge. Your server-side code calls the Verify API to inspect the user’s actions and check their response, with the verification response passed back to your server.

Scenario 3

A user tries to sign on to a website configured for Arkose Detect. The Arkose Labs Platform runs its detection engine. After completion, your server-side code calls the Verify API to inspect the user’s response, with the verification response passed back to your server.

Creating Allowlists and Denylists

You can work with Arkose Labs to define Allowlists and Denylists. Essentially, Arkose takes a list of attributes and values you provide and uses them to create a custom telltale for your sessions. If an Allowlist-associated telltale is triggered, the session is validated, no matter what else happens. If a Denylist-associated telltale is triggered, the session is not validated. This is regardless of any other telltales being triggered.

To create an Allowlist or Denylist telltale, customers create a Zendesk ticket to put an attribute and its value or value range either as in an Allowlist or Denylist (IP values are a frequent choice for list attributes). From that, Arkose will create and set up custom telltales that your Verify API calls will use.

Processing Verify API Responses

🚧

Verify API Field Changes

From time to time, Arkose will add additional fields to the Verify API . We will not either delete fields, or change their value specification (i.e. if field "foo" has been defined as having integer values between 0 and 100, we will not change "foo" so that it has, for example, a string value or integer values between -500 and 5000).

This means you must write your Verify data processing code so it handles unknown fields and their values. For example, suppose it encounters a field "bar" and does not have a defined way of handling "bar" and its value. It could just ignore "bar" as an unknown field and go on to the next field.

SUMMARY:

Arkose will not delete any fields from the Verify API .

Arkose will not change what values a Verify API field can have.

Arkose will add additional fields and their values to the Verify API over time.

Your Verify API data processing code must be able to deal with unknown to it fields and their values in its Verify data input.

Other pages that document the Verify API are: