Pre-Launch Checklist | Parallel Developer 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

On this page

Before launching a server integration in production, there are a few things you should check to ensure you're ready for going live with users.

General Items

  1. Make sure folks on your engineering/product team sign up for our Parallel Developer Updates mailing list (it can be found on the API landing page).
  2. Ensure you can handle both the case of a user sharing their personal information as well as the case of a user sharing a business' information.
  3. It's possible that a user may decline to consent to share information (we need to ask to comply with numerous privacy laws). While this is a rare occurrence, it's one that is possible. See the response parameters section in the Access Token docs for more info.
  4. If an admin at your organization removes access to a user or business from the Parallel dashboard, or if a user decides to stop sharing information, we will notify you (via email and webhooks). You can also see the details around the access expiration in the Profile API.
  5. If you plan on making ongoing requests, make sure you are refreshing tokens so your access tokens don't expire.
  6. If you'd like to keep a user's identity, profile, or accreditation data up to date, ensure you are either scheduling calls to regularly fetch updated data or that you have set up webhooks.

Accreditation

A user or business may indicate that they don't meet the requirements for accreditation (this will be shown in the indicated_unaccredited field). You should make sure you show the user appropriate messaging in this case and, if you believe they could/should meet the requirements, you can tell the user they can submit an application at any time at app.parallelmarkets.com/accreditation.

caution

You should not initiate another Parallel flow if the user has indicated they are not accredited, because we will not start a fresh application (instead, we re-use the assertion that the user is not accredited and immediately send the user back to your interface).

Identity

For Accreditation details users can share their own individual information or the information for a business they control. For identity (KYC/AML) data there is an additional possibility that a user could be sharing information for another individual (see the user_providing_for parameter in the Identity API).