Client Settings | Parallel Developer Documentation

Configuration Access

If you're creating a client in production and need access to your company's account on app.parallelmarkets.com, any of your company's admins can create an account for you.

If you're creating a client in our demo environment for testing and need access to your company's account on demo.parallelmarkets.com, you'll need to reach out to the Partner Integrations Team and request access.

You can add a new client by logging into app.parallelmarkets.com (or, if you're setting up a client in our demo environment for testing, at demo.parallelmarkets.com) and then:

  1. Select your company from the dropdown on the top right of the screen. You should now see your company's dashboard.
  2. Click the "Settings" menu dropdown.
  3. Select "Integrations & Exports".

This will bring you to the "Integrations & Exports" screen where you can add a new client. This is also where you can configure API Keys to make server-based API calls.

Creating Clients

Only company users with the "admin" or "controller" role can create new clients. If you don't see a form to create a new client on your company's "Integrations & Exports" screen, it's likely you don't have sufficient permissions. Please reach out to one of your company's admins or the Partner Integrations Team if you need help.

When adding a new client, there are a number of fields that must be provided:

  1. Client Name: This should be the general name for your company or platform, and will be shown on consent screens as the company that will receive user or business information.
  2. Description: This should be a single phrase (or short sentence, less than 100 characters) that will be shown on consent screens as your company description.
  3. Website URL: This is your public website URL.
  4. Redirect URI: This should be the URL that will include the JS SDK and show the Parallel overlay. This value must exactly match the URL on your site where you will be initiating the overlay (including scheme, host, port, and path). Wildcard domains and Dynamic Redirect URIs are supported in some circumstances.
  5. Terms of Service URL: This should be a public URL where users can see your Terms of Service. There will be a link to these terms on the consent screen that users see.
  6. Privacy Policy URL: This should be a public URL where users can see your Privacy Policy. There will be a link to these terms on the consent screen that users see.
  7. Sign Webhook Requests: Check this box if you'd like Parallel to sign all webhook requests with a shared secret key. A unique key will be generated for the new client. See the section on webhook request signatures for more information on verification. You can ignore this option if you don't intend on using webhooks.

Webhooks and Email Notifications

Once a client is created, you have the ability to provide webhook endpoints in your system as well as email addresses for notifications on a per-client basis.

For accreditation applications, we will call webhooks and send an email to any notification addresses whenever an application is certified, rejected or canceled.

For individual and business identity:

  1. We will immediately call any webhooks whenever we detect a new potential risk match (sanctions, adverse media, etc.).
  2. We will immediately call any webhooks whenever an individual or business updates or submits new data.
  3. We send a daily summary email to notification email addresses (and the individual identified as your primary contact) with a list of any potential sanctions matches found in the last 24 hours.

For more information about our webhooks, see the Webhook Support page.

Redirect URI Wildcard Domains

Some partner platforms provide a custom domain for each issuer on the platform (for instance, https://fund-one.example.com and https://fund-two.example.com). If you want to host the Parallel JS SDK on all subdomains of a top level domain (i.e., "https://*.platform.com") or allow for a server to server redirect URI that could be any subdomain on a top level domain, Parallel systems do allow for the use of a wildcard * subdomain match.

Security Warning

Utilizing wildcard redirect URIs will make your connection less secure. If any of your subdomains are ever compromised, then users could end up sharing information with bad actors. For instance, if you have a documentation site on a subdomain that has a security vulnerability and bad actors are able to write HTML anywhere on the subdomain, they would be able to host a valid copy of the JS SDK and ask users for information.

The concern here is that you may have some sub domains that are less protected (like a support site), and those sites could be used to initiate a Parallel flow that results in sharing information. Requiring that all domains be affirmatively allow-listed via specific redirect URIs mitigates this issue.

Identity Partners

If you are a partner with identity scope access then you won't be able to utilize wildcard domain matching due to the security concerns outlined above.

You can use the star symbol (*) as a wildcard for subdomains when specifying your Redirect URI, but it must be used in accordance with the following rules in order to properly function:

  1. The protocol of the URL must be https:. For instance, com.example.app://*.example.com will not work.
  2. The wildcard must be located in a subdomain within the hostname component. https://*.com will not work.
  3. The wildcard must be located in the subdomain furthest from the root domain. https://sub.*.example.com will not work.
  4. The URL must not contain more than one wildcard. https://*.*.example.com will not work.
  5. A wildcard may be prefixed and/or suffixed with additional valid hostname characters. https://prefix-*-suffix.example.com will work.

A URL with a valid wildcard will not match a URL with more than one subdomain level in place of the wildcard. https://*.example.com will not work with https://sub1.sub2.example.com.

Dynamic Redirect URIs

For partners looking to initiate the Parallel flow on multiple URLs where wildcard domains are not sufficient, generating a signed redirect URI is supported.

This can be done by generating a redirect_uri_signature using the signing key generated for your JavaScript client, and passing this to the login function of the JavaScript SDK.

To use this option:

  1. Create a JavaScript client, ensuring to check the box for "Create a cryptographic signing key to verify signed Redirect URIs."

  2. Click "Show" next to the Signing Key and copy the value. This is the value that will be used to generate the signature in the next step.

  3. Generate a signature for the URI using the following method: base64(HMACSHA256(KEY, QUERYLESS_URL))), where:

    • KEY is the key value copied in step 2.
    • QUERYLESS_URL is the scheme/host/path portion of the URL, without any query string parameters or URI fragments. E.g. https://client-a.parallelbank.com/verification
   // node.js sample - NOTE: THIS CODE SHOULD ONLY RUN ON YOUR SERVER - the KEY value
   // should never be rendered to your frontend, it must remain secret.
   
   const crypto = require('crypto')
   
   // This is the queryless URI where the Parallel flow will be initiated by the SDK
   const QUERYLESS_URL = 'https://client-a.parallelbank.com/verification'
   
   // This is the "Signing Key" copied from the JavaScript client in the Parallel dashboard.
   // Make sure to keep this secret! It should never be exposed to your frontend.
   const KEY = 'KEY_FROM_DASHBOARD'
   
   const decodedKey = Buffer.from(KEY, 'base64')
   const hmac = crypto.createHmac('sha256', decodedKey)
   const sig = hmac.update(QUERYLESS_URL).digest('base64')
   
   // The sig value can be passed to this call in your frontend:
   // Parallel.login({ redirect_uri_signature: "<sig>" })
  1. Pass the generated sig value to your frontend, which should pass this in the redirect_uri_signature option to the Parallel.login() function.
   Parallel.login({ redirect_uri_signature: '<sig>' })

Security Warning

The signing key should never be rendered or exposed to the frontend! It should only ever be used in secure backend code, and should be handled like a secret, similar to an API key. Exposing the signing key could allow malicious sites to host the JS SDK and collect information from your users.