Accredd API Reference

Introduction

Authentication

API Keys

Option 1: Embedded UI API

Option 2: Traditional API

api.accredd.com

Introduction

The Accredd API is RESTful and very easy to integrate. You can use the API without writing a single line of code at api.accredd.com. Please message us at sales@accredd.com for a demo of our API if you are evaluating an integration with us.

There are two implementation options to the Accredd API: Embedded UI and Traditional. We recommend you start with the Embedded UI API because it is the fastest to market (hours instead of days or weeks), and you can always switch to the Traditional API at a later time.

 

Authentication

The Accredd API uses API keys to authenticate requests. You can view and manage your API keys in the Accredd Dashboard.

Your API keys carry many privileges, so please make sure to keep them secured by not sharing your secret API keys in public spaces such as shared docs, GitHub, client-side code, etc.

The API key has two modes: Development and Production. You can easily switch between the modes within the Accredd Dashboard.

API Keys

Accredd authenticates your API requests using your account’s API keys. Accredd will return an invalid request error if your request doesn’t include a valid API key.

Accredd makes revoking or managing an API key very simple. You can create a Development key, a Production key, or change access permissions all with a click of a button.

You can use the Accredd Dashboard to generate and control the API keys between Development mode and Production mode.

Development mode versus production mode

All Accredd API requests happen in either Development mode or Production mode. Use the former to test and access dummy data, in addition to manipulating the status of a submission so you can handle the various scenarios. Switch from Development mode to Production mode when you’re ready to deploy the API in a live environment.

Sandbox Key

Please message us at sales@accredd.com for a demo of our API if you are evaluating an integration with us.

Option 1: Embedded UI API

The Embedded UI API model is useful if you want the fastest time to market and are not interested in building or maintaining an investor verification UI.  The out-of-the-box embedded UI is highly flexible and shipped with many configurable options which you can hide or show based on what information you want the user to see in your application.

  • Obtain an API Key from your dashboard.
  • Call the embed-ui-link to get back an embeddable link.
  • Use the embeddable link in your application.
  • Get the status on a verification submission.  If you are in Development mode, you can set and get different verification statuses to complete your integration.  
  • Seamlessly switch from Development mode to Production mode with the same API Key controls which mode you are in.
  • Optionally, download a verification letter. If you are not interested in storing or managing a verification letter, you can skip this step.
 
Commonly Asked Implementation Questions

How do we preload user info into the modal?

You can save the end user time by passing us information such as their name and whether they’re investing as an entity or an individual. Use the “LegalName” setting and “InvestorType” setting to pass in relevant information. We’ll load this data onto the modal for the end user. “InvestorType” is particularly helpful as it will surface the relevant accreditation options to the user because entities have a different set of accreditation options than individuals.

How can we close the UI modal after a user submits?

To close the UI modal after a user submits their documents, you’ll want to use the “OnVerifyPostMessage” setting. Essentially, your site will wait to get a message from us once the user hits submit. You can then use this message to close the iframe.

How can we pass your feedback to the user?

The endpoint GET/v1/verifications/{transactionID} enables you to get the status for any given submission. If the status is “Failed”, the property “rejectionComment” has a string with specific feedback provided by us. You can pass this along to the end user and enable them to try again.

What is the difference between a transactionID and an ExternalUniqueID?

They are the same. You can pass us an externalUniqueID or we will generate a unique transactionID for you. Either way, you will need this unique ID to get the status for a submission.

How is the PUT endpoint used for development?

The endpoint PUT/v1/verifications/{transactionID} is used to manipulate the status of a submission (“Processing”, “Failed”, “Verified”, “Expired”) during development. This allows you to handle the various scenarios of the submission result.

Why can’t we see any submissions in the “Investors” tab?

The “Investors” tab displays submissions from our standalone app. You can view production API submissions within the “Dashboard” tab by examining the interactive chart “API Count by Status”. It’s best to retrieve the status of your submissions programmatically using the corresponding endpoint. 

 

Option 2: Traditional API

This API model is useful if you want to completely build out your own investor verification UI experience.  We recommend you start with the Embedded UI API model first unless you already have a verification UI or have some special requirements which you find the Embedded UI lacking.  Contact us if you need to talk to one of our experts about choosing an integration model.

  • Generate Obtain an API Key from your dashboard.
  • Submit a new verification.
  • Get the status on a verification submission.  If you are in Development mode, you can set and get different verification statuses to complete your integration.  The API Key controls which mode you are in.
  • Optionally download a verification letter.  If you are not interested in storing or managing a verification letter, you can skip this step.
 
Commonly Asked Implementation Questions

How do we pass in multiple document types?
The properties “Files” and “OtherFiles” are used here. You don’t need to specify the document type as our application will parse them automatically for review.

What unique identifier do we need to give you?

You will use the property “ExternalUniqueID” to pass in a unique string to represent your end user’s submission. You cannot pass in personal identifiable information. If you choose not to pass in a unique ID, we will generate a unique transaction ID for you which you can then use to retrieve the status of a verification within our 12-hour service-level agreement timeframe.

How can we pass your feedback to the user?

The endpoint GET/v1/verifications/{transactionID} enables you to get the status for any given submission. If the status is “Failed”, the property “rejectionComment” has a string with specific feedback provided by us. You can pass this along to the end user and enable them to try again.

What is the difference between a transactionID and an ExternalUniqueID?

They are the same. You can pass us an externalUniqueID or we will generate a transactionID for you. Either way, you will need this string to get the status for a submission.

How is the PUT endpoint used for development?

The endpoint PUT/v1/verifications/{transactionID} is used to manipulate the status of a submission (“Processing”, “Failed”, “Verified”, “Expired”) during development. This allows you to handle the various scenarios of the submission result.

Why can’t we see any submissions in the “Investors” tab?

The “Investors” tab displays submissions from our standalone experience. You can view production API submissions within the “Dashboard” tab by examining the interactive chart “API Count by Status”. It’s best to retrieve the status of your submissions programmatically using the corresponding endpoint.