Migrating from Onboardings to Requirements

Overview

Requirements replace the Onboarding API with a cleaner, more flexible system designed to handle the full lifecycle of verification — not just the initial onboarding of a counterparty.

Here is why we rebuilt it from scratch:

• Document uploads were limited to Users. The previous PUT /kyc/{type} endpoint only worked for Users, and gave you no way to specify whether you were uploading the front or back side of an identity document.
• No support for new verification types. The Onboarding model was document-centric and couldn't accommodate new check types such as Liveness or future contract-based requirements.
• No visibility into who needs to provide what. With Onboardings, you knew a document was required — but not which specific individual was expected to provide it. Requirements introduce eligibleParties so you know exactly which person needs to act.
• A cleaner status model. The Onboarding API had a fragmented status lifecycle: you had to track the multiple onboarding documents status for one document type. Requirements will return instead one main status per document type and one status per eligible party.

What Changed

What's New

• New requirement types: Support extends beyond document collection to include LIVENESS for Debtors and similar checks previously incompatible with the Onboarding model.
• One status per requirement type: Each requirement carries its own status, aggregated from eligible parties status. Previously, tracking required monitoring onboarding status separately from document upload statuses.
• Eligible parties: Requirements now expose one or more eligibleParties: individuals or companies fulfilling them. Satisfaction occurs when one party validates (OR logic). Each party includes validationStatus and refusalReasons.
• Resolution methods: resolutionMethods supersedes the single portalUrl field, supporting both portal and api resolution types.

Webhook Migration

API Migration