OAuth Client Settings | Parallel Developer Documentation

Parallel Developer Documentation Legacy – v1.x

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

Configuration Access

If you're creating an OAuth 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 an OAuth 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 OAuth 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".

You should now see a screen where you can add a new OAuth Client.

Creating Clients

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

When adding a new OAuth 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:
    • For a server to server integration, this should be the location where you want users to be redirected after they complete a flow on Parallel. This value must exactly match the full location (including scheme, host, port, and path) where you want to send the user after they complete a flow.
    • For a JS SDK integration, this should be the URL that will be including the JS SDK and showing 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 are supported in some circumstances, see below for more information.
  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 OAuth 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 an OAuth 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 tokens 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 tokens.

The concern here is that partners 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 tokens. 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.