This guide explains how to integrate Ondorse into your existing prospects and clients management workflows. It covers integrations with:

• CRMs such as Salesforce and HubSpot
• Back-office operations management systems
• Customer-facing web and mobile applications

Integration types

In our experience, we've encountered 5 types of integration of Ondorse:

[1]: managed onboarding = a dedicated person guides the client through the process.

[2]: We provide dedicated assistance for such projects, please reach out.

Ondorse functional overview

Ondorse is a platform that orchestrates the verification process (KYC) of your client (businesses or natural persons) in order to:

• complete a client compliance profile
• make a compliance decision wether to onboard this client or not

The client is deemed verified from a compliance perspective when a compliance decision is output.

In Ondorse, a client record corresponds to case. The case holds the whole compliance profile of the client which includes documents, attributes, verification points, risk profile and more.

Collect: in this process, to complete the case, data are prompted from the client using a white-labeled client-facing interface provided by Ondorse, called a portal. (Alternatively, you can choose not to use Ondorse's provided portal and instead modify your own customer-facing interface: see headless integration.)

Re-collection: after an initial collect and review of the case, it may happen that corrections or additional informations (extra due diligence) are required from the the client. In this situation, additional data and corrections can be prompted from the client, still using portal.

Data model

Common integration touchpoints

Most integration points and related questions center around these 3 areas:

• Input: How does a client record from your system enters Ondorse as a case?
• Output: How does a case decision and some parts of the client profile are reported back into your system?
• Client prompting: How to integrate portal into your client flow? How does your client access the portal?

With a user-facing web application

Using portal: redirections

This example integration plugs into your application's sign-up flow: your app creates the customer account but keeps it inactive, then redirects the user to an Ondorse portal URL to complete the KYB flow (business info, persons, documents). After submission, the user is redirected back to your app while verification runs in the background.

Until the KYB verification is approved, the customer account stays inactive with limited access to your application (e.g., wire transfers disabled). This design has several advantages:

• While verification is pending, the user already has access to your application — you can build engagement: complete setup, train the user, etc.
• Creating the account first gives you more ways to contact and re-engage the user in case of drop-off.
• You can pass down case-specific information, such as internal references (e.g. account_id) or risk data (e.g. acquisition channel).

If extra due diligence is needed, the portal will be re-opened, containing the necessary instruction for the user to continue the process (additional document, correction..). You can plug into a webhook to catch this portal re-opening.

Once the case is approved, a webhook will be trigged: use it to activate the account.

Endpoints

• Use the endpoint POST /api/portals (reference) to create a Portal link:
  • use the param default_custom_fields to pass custom case data such as account_id etc..
  • use the param redirect_url to redirect the user after the submission of the Portal
• Use the webhook event application.submitted to be notified when a case is submitted via Portal
  • in the payload, you have access to the application_id and custom_fields values (especially the ones coming from default_custom_fields)
• Use the endpoint GET /api/applications/{application_id} (reference) to get access to case content
  • use the field status_review to know the decision status
  • use the fields risk_score and risk_level to get information about the risk scoring
• Use the webhook event application.review_updated to be notified when a case gets an update on its status_review
• Use the webhook event collect.opened to be notified when a case needs an information from the customer
  • Use payload data.object.portals.link to access the link to the collect Portal that you can send to the customer.

Without using portal: headless integration

In a headless integration, you build 100% of the client-facing experience yourself and use Ondorse purely as a compliance back office (case manager). No Ondorse portal is shown to your client — every field, document, and status update flows through your own UI using the Ondorse API as source.

Endpoints

Find below the endpoints that you can use to build a flow that re-creates portal flow as described in the section above.

The KYB/C profile is embodied by the objects Application , Business and Person. Refer to the documentation for the schema of a KYC profile expected by Ondorse.

Note that these objects can expect Custom fields, defined on your account.

⚠️ Never call these endpoints from a browser or mobile client directly — proxy them through your own backend so your ONDORSE_API_KEY is never exposed client-side.

Autofill

To provide an autofill experience, use the endpoint GET /api/companies/{country}/{registration_number} (reference) to gather data from official registry once you have an exact registration number. If found, it will return company data acceptable for Application , Business and Person.

⚠️ a free-text GET /api/companies/{country}/search?q=... also exists behind the same auth, but it's excluded from the public API schema as of today.

Basic information

Use the endpoint POST /api/applications (reference) to create the case as a draft:

• if the case is a KYB (subject is a business entity), use business to pass the entity under verification (organization_name, country, registration_number), otherwise use person (subject is a natural person).
• use external_reference to store your own internal client/account ID
• set is_draft: true so the case doesn't enter the compliance workflow yet

Use the endpoint PUT /api/applications/{application_id} (reference) to update the case as the client fills in more data, e.g. to set custom_fields.

Related parties

• Use the endpoint POST /api/applications/{application_id}/persons (reference) to add each related natural person (director, UBO...):
  • use roles (e.g. ACCOUNT_OWNER) and direct_ownership_percentage to describe their relationship to the case
• Use the endpoint POST /api/applications/{application_id}/businesses (reference) to add each related legal entity the same way.

Documents

• Use the endpoint POST /api/files (reference) to upload a document's binary:
  • send it as multipart/form-data and let your HTTP client set the Content-Type/boundary — don't set it manually
  • this only returns a file_id; it doesn't attach anything to the case yet
• Use the endpoint POST /api/documents (reference) to attach an uploaded file to the case or a person, using the file_id from the previous step and a type (e.g. ID).

Submission

• Use the endpoint PUT /api/applications/{application_id}/submit (reference) to submit the case, with no body. This takes it out of draft and into the compliance workflow.

Decision notification

Use the webhook event application.review_updated (reference) to be notified when a case gets a decision.

• Read the field status_review via GET /api/applications/{application_id} (reference) to get the decision

Recollection

Use the webhook event collect.opened to be notified when a case needs an information from the customer

• Use payload data.object.portals.link to access the link to the collect Portal that you can send to the customer.

Advanced capabilities

The following aren't limitations — they're possible today, but aren't the most popular design choices and usually benefit from a bit of guidance from our team. Reach out to your Ondorse contact before building.

Dynamic form driven by Ondorse configuration: adapting which fields/documents you ask for as the client fills in the form, driven by Ondorse's Activation conditions.
Why: in a headless integration, it's usually easier to implement these conditions in your own code rather than relying on Activation conditions.

Embedded identity verification (IDV): submitting your own IDV provider's result into a case without going through Portal.
Why: in a headless integration, it's usually easier to integrate the IDV provider directly, without Ondorse's involvement, then push the IDV proof and details into Ondorse as standard documents.

Headless re-collection: requesting corrections or additional documents from the client without opening a Portal.
Why: in a headless integration, it's usually more convenient to rely on Ondorse's Portal for re-collection, since re-collection flows are less frequent and happen outside your application's main sign-up flow.

Live AI document checks: surfacing AI document validation feedback to your client in real time as they upload, rather than after the fact.

With a CRM (e.g., Salesforce)

In this example, we present an integration with Salesforce.