Parallel Markets API Documentation

This is documentation for Parallel Developer Documentation Legacy – v1.x, which is no longer actively maintained.

For up-to-date documentation, see the latest version (Current – v2.x).

Version: Legacy – v1.x

The Parallel Markets API allows users to assert their identity and accreditation status on other websites. Users have a portable investor identity that enables authentication and authorization on third-party platforms without repeated accreditation verification.

JavaScript Option

This section does require custom code on your backend server. Our JavaScript SDK allows you to avoid server side code and operate entirely on the frontend as another option.

OpenAPI / Swagger Specification

Download parallel-api.swagger.yml and import it into your tool of choice or the Swagger Editor. See the OpenAPI Swagger Specification for more information.

Introduction

The Parallel Markets API uses the OAuth 2.0 protocol for authentication and authorization, which is the same standard protocol used by the big identity providers (like "Sign in with Google", "Facebook Login", etc). To begin, OAuth 2.0 client credentials can be created in the settings area for your business. Then your client application requests an access token from our OAuth Token API, extracts a token from the response, and uses the token in Parallel API calls for authentication on behalf of the user.

OAuth Basic Steps

All applications follow a basic pattern when accessing the Parallel Markets API using OAuth 2.0. At a high level, you follow these steps:

1. Obtain OAuth 2.0 client credentials from Parallel Markets support. This will be in the form of a client id and a client secret. You can also create these credentials in the admin section of your partner dashboard.
2. Obtain an authorization code from the Authorization Server. Your application will send users to the Parallel Markets site at a specially crafted URL that describes the information you'd like to access (for instance, accreditation or KYC/AML data). The user will then be prompted to authenticate (or create an account). After logging in, the user is asked whether they are willing to grant the permissions that your application is requesting. If the user grants consent, they are sent back to your site with a short lived "authorization code". This process is described in more detail in the Access Token documentation.
3. Convert an "authorization code" to an "access token." Once you have an "authorization code", you can call the Token API to fetch a long lasting token to be used for future API calls on that user's behalf. Each access token will grant access to our APIs on behalf of a single business or individual, based on the permissions they granted when initial authenticating in the previous step.
4. Use the access token to make calls to the API. Once you have an access token, you can make calls to the various API's by simply adding the token to the request in the HTTP authorization header.
5. Refresh the access token. Access tokens have limited lifetimes. If your application needs access to the API beyond the lifetime of a single access token, you can obtain a refresh token. A refresh token allows your application to obtain new access/refresh tokens, keeping access possible on an ongoing basis for perpetuity.