new Add support for specifying language when creating a case.

• POST /v2/accounts/{aid}/cases

new Add support for creating case from a template.

• POST /v2/accounts/{aid}/cases

new Add support for managing case templates

• POST /v2/accounts/{aid}/templates
• GET /v2/accounts/{aid}/templates
• GET /v2/accounts/{aid}/templates/{tid}
• PATCH /v2/accounts/{aid}/templates/{tid}
• DELETE /v2/accounts/{aid}/templates/{tid}

new Add support for creating case on individuals.

• POST /v2/accounts/{aid}/cases

new Add support for exporting case events. Only supports exporting to a json file.

• POST /v2/accounts/{aid}/cases/{cid}/events/export

new Add support for notifications on case details

• GET /v2/accounts/{aid}/cases/{cid}

new Add percent_voting_shares and percent_voting_shares_range fields to ultimate_beneficial_ownership prefill. This field will contain the percentage ownership shares of the ultimate beneficial owner.

• GET /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

2023-09-08

new Add support for filtering cases on case ID with the search parameter.

• GET /v2/accounts/{aid}/cases

new Add support for attachments in unsigned contracts. This field will contain the contract to be signed by the signatory.

• GET /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}

new Add branding images and company details of an account to UserAccount object.

• GET /v2/account/user

new Add unique flags for check summary when retrieving cases.

• GET /v2/accounts/{aid}/cases

new Add support for adding commitment data to subscription in Account object.

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for settings field in Account object. Currently only inspect_mode is supported.

• POST /v2/accounts/{aid}/accounts

new Add support for filtering cases by new query parameters: country, sort_by, and sort_order. search has also been extended to support search on organization number and name of a company

• GET /v2/accounts/{aid}/cases

new Include partner.type in Account. This field contains the information about the partner type of the account.

• GET /v2/accounts/{aid}/accounts

new Include name in Account. This field will contain the name of the account. Fallback to company.name if not set. This field can be set when creating and updating a account.

• GET /v2/accounts/{aid}/accounts
• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Include form_submitter in Case. This field will contain the information about the user who submitted the form.

• GET /v2/accounts/{aid}/cases

new Add support for filtering accounts by new query parameters: created_by, type, company.country and status

• GET /v2/accounts/{aid}/accounts

new Add support for specifying type and status when creating new and updating account

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for subscription field in Account object. This field will contain the information about the subscription enabled on the account and products available for reseller accounts.

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for ANY_TWO_BOARD_MEMBERS as a signatory signing option.

new Add support for signed_result field in signed contract object. This field will contain the information about the signee from the signing provider. Currently 'BankID' is the only supported signing provider.

breaking background_color_email in branding is removed in favor of background_color_header.

new Add support for COMPANY_TYPE_NOT_SUPPORTED flag in ultimate_beneficial_ownership and credit_score checks.

new Add support for pdf_logo in branding which will be used in all generated contracts.

breaking The generated contracts will no longer use the logo field in branding and will use pdf_logo instead.

new Extend notes section types to include credit_score, case_approved and case_declined.

new Add declared_at field to the cases for both case lists and case details.

new Add support for additional_details in sections for swedish_company, also adds industry_sectors for swedish companies.

new Add support for SanctionedOrganizationRecord in sanction checks which returns a list of sanctioned organizations that match the provided information.

new Add support for current_information field in case details.

new Add support for details fields in case checks to provide additional information to the check flags. Currently we only support DATA_MISMATCH flag.

The API is built around RESTful architecture utilizing predictable and resource-oriented URLs. Request bodies and responses are JSON-encoded. Standard HTTP response codes, authentication methods, and verbs are used to maintain consistency and ease of use. Authenticating an API request requires an API key provided by our dashboard, allowing the user to choose between test mode or live mode.

Authentication is done by using a Bearer token, which can be requested by using the API key provided by your dashboard. The token is valid for 1 hour and can be refreshed by requesting a new token.

To request a token, simply send a request to /auth/token with the Authorization header set to Bearer their-api-key. In response, a unique access token will be provided which remains active for one hour.

Note: Please prefix all API requests with v1/accounts/{aid}.

Example request: Requesting access token with API key

POST /auth/token HTTP/1.1
Host: example.com
Authorization: Bearer YOUR_API_KEY_FROM_DASHBOARD

Example response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123

{
  "access_token": "your_access_token_here",
  "token_type": "Bearer",
  "expires_in": 3600
}

All subsequent requests to the API must include the Bearer access token in the Authorization header.

Example request using the returned access token to list cases:

GET /cases HTTP/1.1
Host: example.com
Authorization: Bearer {access_token}

The API flow is centered around three core components:

• Cases, which represent a unit of work within the system and contain relevant documents and information required for compliance.
• Contracts, which are optional and serve as a formal agreement between customers and their clients or counterparts to comply with KYC and AML requirements.
• Checks, which are the various procedures performed to verify the identity and authenticity of individuals or entities involved with a particular case.

A case is a unit of work for the Quickr API. It contains all the information required to perform a compliance check together with any documents, information, checks, and check results associated with the case.

Creating a case

A case can be created by sending a POST request to the /cases endpoint. The response will contain a unique identifier for the case, which can be used to retrieve the case at a later time.

• prefills : Prefills in Quickr enable you to pre-populate information into the declaration form to simplify and speed up the declaration process. You can use this feature to provide information you already have about the entity or include custom information. By providing the company prefill's organization_number and country fields, Quickr can automatically fill out the related company, signatory, and ultimate_beneficial_owner prefills on your behalf.

Example request:

{
"publisher": {
  "name": "Your company name",
  "support_email": "support@company.com"
},
"prefills": [
  {
    "type": "company",
    "data": [
      {
        "organization_number": "919656395",
        "country": "NO"
      }
    ]
  }
],
"sections": [
  {
    "type": "company"
  },
  {
    "type": "ultimate_beneficial_ownership"
  },
  {
    "type": "signatory"
  }
]
}

• sections : These are the sections that will be shown in the declaration form. You can choose which sections you want to show in the form.

• checks : These are the checks that will be performed on the case. Note that some checks may require specific information to be provided in the case. For example signatory check requires signatory section to be present in the case.

  Available checks:

  • company : Checks a company's information provided in the declarations against the company's in the prefills section and the company status from information in the public register as well as against sanction lists.

  • signatory : Checks a signatory's information provided in the declarations against the signatory's information in the prefills section, and the received after the signatory has signed a contract.

  • individual : Checks an individual information provided in the declarations against the individual's information received after the individual has verified their identity

  • ultimate_beneficial_ownership : Checks a ultimate beneficial owner's information provided in the declarations against the ultimate beneficial owner's information in the prefills section,

  • sanctions : Checks the company , signatory and ultimate_beneficial_ownership information against the sanction and criminal lists.

  • politically_exposed_person : Checks the company , signatory and ultimate_beneficial_ownership information against the politically exposed persons lists.

  • bank_account : Requires bank_account section to be present in the case. Checks the validity of the bank account and if the entity is the owner of the bank account.

  • credit_score : Requires company section to be present in the case. Checks the credit score of the company. Also populates the discoveries field with the credit score information.

  • agreement : Requires agreement section to be present in the case. Checks if the user accepted custom agreements passed in the agreements prefill.

  Note: If a case is created with only credit_score check and prefills, the case will automatically be completed with the credit_score check result.

Case lifecycle

A case can follow one of the following life cycles:

Case with signing requirement

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case with `declaration_url`
      alt intent "declarations_update"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      else intent "declarations_finished"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      end
      User->>QuickrApi: GET cases/:cid/contracts/:contract_id/signatories/:sid/sign
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Case without signing requirement

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case with `declaration_url`
      alt intent "declarations_update"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      else intent "declarations_finished"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      end
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Case with credit_score check only

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Contracts are agreements between a customer and their customer, detailing the terms and conditions of their business relationship.

Checks are the various procedures performed to verify the identity and authenticity of individuals or entities involved, and(or) other custom information with a particular case. Checks are performed automatically once a case declaration is completed and the case does not require signing, after the case has completed the signing process, or immediately after the case is created if the case only requires a credit_score check.

Check scheduling

Quickr supports scheduling of checks for Ongoing Due Diligence (ODD) and Know Your Customer (KYC) processes. Checks can be scheduled to run at a specific repeating predefined interval. Currently, the following intervals are supported: R-1/P1D(Daily), R-1/P1M(Monthly) and R-1/P1Y(Yearly) intervals. The initial check intervals are determined from when the check initially runs see above. The interval is set per check type by using the schedule field in the check object. The schedule field is a string that contains the interval in ISO 8601 format.

For example adding a daily PEP check to our previous example the request would look like this:

POST /cases
Authorization: Bearer <token>

{
    "publisher": {
        "name": "Your company name",
        "support_email": "support@company.com"
    },
    "prefills": [
        {
            "type": "company",
            "data": [
                {
                    "organization_number": "919656395",
                    "country": "NO"
                }
            ]
        }
    ],
    "sections": [
        {
            "type": "company"
        },
        {
            "type": "ultimate_beneficial_ownership"
        },
        {
            "type": "signatory"
        }
    ],
    "checks": [
        {
            "type": "politically_exposed_person",
            "options": {
                "schedule": "R-1/P1D"
            }
        }
    ]
}

For all checks after the initial check has run, Quickr will also get updates on the case from public registries and other third party sources to ensure that the case is up to date, before running the check. You will receive a notification(s) when the check has been completed which will contain the results of the check and updates to the case if any. Notifications are sent via webhook if your case has a callback_url set. The notification will be sent when the checks are completed and contains changes(if any) from the check results since the last check. More information on this can be found in the Case Events section.

Adding a callback url to our previous example the request would look like this:

POST /cases
Authorization: Bearer <token>

{
    "publisher": {
        "name": "Your company name",
        "support_email": "support@company.com"
    },
    "prefills": [
        {
            "type": "company",
            "data": [
                {
                    "organization_number": "919656395",
                    "country": "NO"
                }
            ]
        }
    ],
    "sections": [
        {
            "type": "company"
        },
        {
            "type": "ultimate_beneficial_ownership"
        },
        {
            "type": "signatory"
        }
    ],
    "checks": [
        {
            "type": "politically_exposed_person",
            "options": {
                "schedule": "R-1/P1D"
            }
        }
    ],
    "urls": {
        "callback_url": "https://yourdomain.com/callback"
    }
}

Check results

Check results can be found in the checks field of the case by querying the cases/:cid endpoint. The checks field contains an array of check results one for each check performed on the case. The flags field contains an array of flags that were found during the check. The discoveries field contains an array of discoveries that were found during the check.

Available flags codes:

Some common flag codes are:

• DECLARATION_MISSING : Which indicates that the declaration is missing.
• PREFILL_MISSING : Which indicates that the required prefill is missing.
• DATA_MISSING: Which indicates that required data is missing.
• DATA_MISMATCH: Which indicates that the data provided in the declaration does not match the data in the prefill.
• DATA_MANUAL_UPDATE: Which indicates the data provided in the declaration has been manually updated from the prefill.
• DISCOVERY_MISSING: Which means Quickr was unable to find entity/persons information in the public register/data source.

Some check specific flag codes are:

• company : A company check may contain the following flag types:
  • COMPANY_INACTIVE : Which indicates that the company is inactive from the public register.
  • COMPANY_IN_SANCTIONS : Which indicates that the company is in the sanction list.
• signatory : A signatory check may contain the following flag types:
  • CONTRACT_NOT_SIGNED : This means that the contract has not completed the signing process.
  • SIGNATORY_MISMATCH : This means that the signatory information provided in the declaration does not match the signatory information from the signed contract information.
• ultimate_beneficial_ownership : A ultimate beneficial ownership check may contain the following flag types:
  • PERSON_IN_SANCTIONS : Which indicates that the person is in the sanction list.
  • PERSON_IN_PEP : Which indicates that the person is/is affiliated with a politically exposed person.
  • COMPANY_TYPE_NOT_SUPPORTED : Which indicates that Quickr does not support this check for the company type. In most cases this means that the company type is a sole proprietorship.
• politically_exposed_person : A politically exposed person check may contain the following flag types:
  • PERSON_IN_PEP : Which indicates that the person is/is affiliated with a politically exposed person.
• sanctions : A sanctions check may contain the following flag types:
  • COMPANY_IN_SANCTIONS : Which indicates that the company is in the sanction list.
  • PERSON_IN_SANCTIONS : Which indicates that the person is in the sanction list.
• bank_account : A bank account check may contain the following flag types:
  • BANK_ACCOUNT_NUMBER_INVALID : Which indicates that the bank account is invalid/is not owned by the entity.
  • BANK_ACCOUNT_NUMBER_UNSUPPORTED : Which indicates that Quickr cannot verify the bank account number. Currently only Norwegian bank account numbers are supported.
• credit_score : A credit score check may contain the following flag types:
  • COMPANY_HAS_HIGH_RISK : Which indicates that the credit score is lower than Quickr's set threshold, which is 30%.
  • COMPANY_HAS_PAYMENT_REMARKS : Which indicates that the company has some negative payment remarks.
  • COMPANY_TYPE_NOT_SUPPORTED : Which indicates that Quickr does not support this check for the company type. In most cases this means that the company type is a sole proprietorship.
• agreement : An agreement check may contain the following flag types:
  • AGREEMENT_NOT_ACCEPTED : Which indicates that the user has not accepted the agreement.

Note: Some checks flags records may contain a records field which contains an array of records that caused the flag to be raised. For example, the sanctions check flags record may contain a records field that caused the PERSON_IN_SANCTIONS flag to be raised.

The token endpoint is used to get the JWT (JSON Web Token) that must be passed in every API request in the Authorization header.

• The access token is valid for 1 hour

As an partner you can create additional Quickr customer accounts associated with you partner account.

You must use separate Quickr accounts for customers that operate independently from one another. When you activate a new account, it is subject to Quickr's standard policies and pricing.

You can invite members of you team to access your Quickr account.