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.
| Onboarding Concept | Requirements Equivalent |
|---|
Onboarding | Requirement with type: ARIA_VALIDATION |
Onboarding.portalUrl | Requirement.resolutionMethods[].url (where type is portal) |
Onboarding.status | Requirement.status |
Onboarding.refusalReasons | EligibleParty.refusalReasons |
Onboarding.targetId / targetType | Requirement.targetId / targetType |
OnboardingDocument | Requirement (each document type becomes its own requirement) |
OnboardingDocument.type | Requirement.type (ID_DOCUMENT, UBO, etc.) |
OnboardingDocument.status | EligibleParty.validationStatus |
OnboardingDocument.refusalReasons | EligibleParty.refusalReasons |
- 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.
| Old Event | New Event | Notes |
|---|
onboarding.created | requirement.created | For ARIA_VALIDATION type only |
onboarding.updated | requirement.updated | For ARIA_VALIDATION type only |
| (no equivalent) | requirement.updated | New. Previously unavailable: track aggregated requirement status changes |
| _(no equivalent) | requirement.created | New. Previously unavailable: track aggregated requirement creation |
| (no equivalent) | requirement.waived | New. Fired when all eligible parties are waived, meaning that we don't need that requirement anymore for now. |
onboarding.document.created | requirement.eligible-party.updated | - |
onboarding.document.updated | requirement.eligible-party.updated | - |
| (no equivalent) | requirement.eligible-party.waived | - |
| Old Endpoint | New Endpoint |
|---|
GET /companies/{companyId}/onboardings | GET /companies/{companyId}/requirements?filter=eq(type,ARIA_VALIDATION) |
GET /companies/{companyId}/onboardings/{onboardingId} | GET /companies/{companyId}/requirements/{requirementId} |
PUT /companies/{companyId}/user/{userId}/kyc/{type} | POST /companies/{companyId}/requirements/{requirementId}/eligible-parties/{eligiblePartyId}/submit |
