Start the journey
Your web, mobile or back-office application creates and resumes the KYC application.
A robust KYC API integration turns compliance policy into predictable outcomes. It connects your product to data providers, identity verification, sanctions and PEP screening, adverse media, and risk decisioning so signups, monitoring, and remediation move at production speed. The goal is reliability you can trust: predictable contracts, idempotent calls, signed webhooks, clean event models, and SLAs that hold under load. This page covers practical patterns for connecting Ondorse, including payloads, retries, observability, security versioning, and testing strategies that survive real traffic.

A modern integration is more than a single endpoint. It is a system of contracts, payloads, and lifecycle events that the rest of your platform can rely on for every signup and case.
The pieces below cover what teams actually wire on day one and keep stable as they scale.
Identity verification API with document, selfie, and proof-of-address checks normalized across vendors.
Company data API with registry lookups, UBO discovery, and watchlist coverage.
Sanctions, PEP, and adverse media screening with explainable matches and configurable thresholds.
Risk scoring API that turns signals into decisions and reason codes you can audit.
Webhooks and event models so case management, analytics, and downstream services stay in sync.
.webp)
.webp)
Stable contracts prevent breakage and make audits predictable. Think in resources, states, and transitions rather than ad hoc endpoints.
Model an application resource that owns sub-resources like document checks, biometrics, and screening. Each sub-resource moves through states such as created, pending, completed, or failed. Expose state changes as events so consumers do not need to poll.
Integrations fail when payloads drift. Normalization keeps downstream logic portable across vendors.
Canonical fields with consistent names like name, date_of_birth, address, nationality, document_type.
Structured outcomes that separate result, score, and reasons instead of mixing them in text.
Evidence references that store URLs or IDs for images, OCR text, and screening matches.
Timestamps and IDs on every call, plus your own idempotency key scoped to operation and resource.
Unicode hygiene: normalize to NFC, store raw and normalized forms for names and addresses to avoid false mismatches.
Some checks finish quickly while others take longer. Mixing sync steps with async updates keeps UX responsive without losing reliability.
Keep the user in flow for short steps like basic document validation. Switch to webhook driven updates for heavy screening or manual review. Always return a stable application_id so the client can poll if webhooks lag.
Networks fail and vendors hiccup. Reliable KYC API integration treats these as routine.
Client retries with exponential backoff and jitter for safe operations only.
Idempotency keys on POST create calls so resubmits do not duplicate work. Store keys with a TTL matched to user retries.
Sensible timeouts per call type and fallback routes in the orchestration layer.
Error taxonomy that separates user errors from transient vendor incidents and rate limits.
Webhooks reduce polling and align teams, but only if events are clear and secure.
Emit domain events like application.created, document.updated, identity_verification.updated, and application.status_updated. Sign payloads with an HMAC secret in a dedicated header, include a monotonically increasing event_id, a timestamp, and allow safe replay. Receivers should write events to durable storage before processing to avoid loss.
Identity data is sensitive. Security is not a wrapper, it is part of the contract.
TLS everywhere and encryption at rest with managed key rotation.
Role-based access control, SSO, and field level permissions for sensitive attributes.
Data minimization and short retention with explicit deletion flows per regulation.
Scoped API tokens, IP allowlists, and secret rotation for webhook signing keys.
PII segregation so analytics receives tokens or hashes instead of raw data.
A good sandbox beats a thousand mocks. Test with realistic samples, slow networks, and messy inputs.
Go beyond happy paths. Prove behavior under stress and ambiguity.
Document edge cases like glare, blur, partial crops, and expired IDs.
Biometric variations with lighting changes, accessories, and low end cameras.
Screening matches that include true positives, false positives, and partial name collisions.
Network chaos such as timeouts, retries, webhook delays, and out of order events.
Locale coverage for non Latin scripts, address formats, and encodings.
You cannot improve what you cannot see. Instrument from day one and agree on SLAs that reflect business needs.
Track a small set of indicators and wire alerts humans can act on.
Pass rate and drop-off by step, country, and device profile.
Latency per provider and check type with p50, p95, and p99.
Error budgets and incident counts per dependency.
Webhook health including delivery success, delay, and replay rate.
Vendor payloads evolve. Without versioning, every update becomes a fire drill.
Use explicit API versions in URLs or headers. Deprecate with dual write and dual read windows. Maintain a visible changelog and notify consumers in advance. For risky changes, introduce feature flags and shadow traffic before switching. Ondorse favors policy as code and versioned rules so risk updates do not require an app release.
KYC API integration lives between product, risk, and data. The goal is to remove blind spots, not create new silos.
KYC workflow on the front end that requests only what each segment needs.
KYC orchestration to route by country, device risk, or backlog and to define fallbacks.
Customer risk assessment that turns raw signals into scores and paths.
AML case management for investigations with evidence and maker checker.
Data warehouse and BI to analyze acceptance rate, false positives, and unit economics.
A short scenario shows how pieces fit together in production. An IDV provider times out for a specific device slice. Your client retries with backoff, then your orchestration switches to a fallback. Both attempts are logged with the same idempotency key. A webhook arrives late but is verified by signature and timestamp and is safely deduplicated by event_id. The decision is recorded with reason codes and evidence links. When an auditor asks three months later, you pull the exact chain in minutes.
Big bang releases increase risk. A phased approach proves value and keeps audits predictable.
Use a narrow start and expand on evidence, not on hopes.
Define risk segments and required checks for each including evidence to store.
Design payloads and event names up front in a shared schema repo.
Integrate one provider per check type, set timeouts, retries, and idempotency rules.
Wire webhooks with signed payloads, timestamp checks, and safe replay.
Instrument metrics and alerts. Ship to one market, compare pass rate, latency, and cost.
Roll out gradually and maintain a change log with rationales and outcomes.
Updated October 2025: reviewed by a compliance engineer and aligned with public guidance from FATF and European supervisory bodies.
If you are scoping a KYC API integration, start with a contract and event model that your platform can rely on. Choose a partner that ships idempotency, signed webhooks, predictable retries, and clear versioning. Ondorse provides these building blocks plus orchestration and case management so teams can move from pilot to production with confidence.
Teams often ask how to keep conversion high, choose between SDKs and direct APIs, or handle incidents. The answers below cover common points without hand waving.
SDKs speed up delivery and raise capture quality on mobile. Direct APIs give maximum control but require more engineering and QA. Many teams start with SDKs and add direct capture where customization is essential.
Use risk based onboarding. Keep light paths for clean segments and escalate only when signals justify it. Measure step level drop-offs and remove friction that does not change outcomes.
Your orchestration layer should switch to a fallback provider or queue work until recovery. Alert on timeout rates and return clear status so users are not stuck in limbo.
Connect onboarding, verification, screening and decision events through stable resources and predictable states. Design for retries, delayed results and provider incidents from the first release.
Need multi-provider routing? Explore KYC orchestration.
POST /v1/applications
Idempotency-Key: app_01J8...
{
  "external_id": "customer_84721",
  "workflow": "business_onboarding",
  "country": "FR",
  "redirect_url": "https://app.example.com/return"
}
202 Accepted
{ "id": "app_84721", "status": "pending" }
Illustrative contract. Confirm against Ondorse docs.A KYC API integration connects a product and its internal systems to customer verification, AML screening, risk decisions and review outcomes through defined resources, requests and lifecycle events.
The integration is more than one verification call. It must coordinate customer data, long-running checks, webhooks, evidence, errors, user-facing status and later monitoring events without creating duplicate applications or inconsistent decisions.
The API is the connection surface. KYC orchestration manages provider execution behind that surface, while the KYC workflow defines the business stages and outcomes.
Treat the integration as a small distributed system. Each component needs a clear owner and failure behaviour.
Your web, mobile or back-office application creates and resumes the KYC application.
Stable endpoints validate data and return resource identifiers and status.
The workflow and orchestration layers coordinate verification and screening.
Signed events communicate check, case and decision updates.
Product, CRM, data and operations systems react to finalised states.
A central application resource gives downstream systems one stable identifier for the customer journey and its related checks.
Names shown here are illustrative. The final page must use the exact resources and fields from the current Ondorse API reference.
applicationOwns customer context, workflow selection, overall status and final decision.
partyRepresents the person, company, representative or beneficial owner being checked.
checkTracks a verification, screening, registry or other task and its result.
caseRepresents an exception requiring evidence, assignment or human judgment.
evidenceReferences the documents, source results or artefacts associated with an outcome.
eventCommunicates an immutable lifecycle change to authorised consumers.
Clients need to distinguish ongoing work, a customer action, human review, completion and technical failure.
createdThe resource exists but execution has not started.
pendingA check or workflow action is still in progress.
action_requiredThe customer or an operator must provide information.
review_requiredThe outcome needs authorised human judgment.
completedThe resource reached a final successful state.
Technical failures should not be represented as customer risk outcomes. The final taxonomy must match the actual Ondorse API.
Keep synchronous responses short and predictable. Use events for work whose duration depends on providers, customer action or review.
Useful when the API can validate and create a resource within a controlled request window.
Useful for document checks, screening, provider calls and review decisions that may finish later.
Retries and network uncertainty are normal. The integration should produce the same logical outcome when a safe request or event is delivered more than once.
Associate a client-generated key with the operation and resource for an appropriate retention period.
Idempotency-KeyUse timeouts appropriate to the endpoint and avoid leaving a client in an unknown state.
202 AcceptedUse exponential backoff and jitter only where the operation and error classification permit it.
Retry-AfterStore event identifiers before applying downstream changes and tolerate redelivery.
event_idEvents should describe completed domain changes with stable identifiers, timestamps and versions.
Sign payloads, document retry behaviour, support safe replay and give consumers enough information to retrieve the authoritative resource.
application.createdA new application resource is available.
identity_verification.updatedAn identity verification reached a new result.
collect.openedA document collection was opened to gather additional customer evidence.
review.openedA case was opened and requires authorised review.
application.status_updatedThe application status changed after a governed decision.
Event names are illustrative and must be replaced by the exact current Ondorse event catalogue.
Errors should tell the caller whether to correct input, retrieve an existing resource, wait, retry safely or stop.
A field, format or business precondition is invalid.
Authentication or authorisation does not permit the operation.
The operation conflicts with the current resource or idempotency state.
Capacity, dependency or service conditions prevented completion.
The exact Ondorse controls should be confirmed through its documentation, security page and customer security review.
Use separate environments, least-privilege access and an explicit rotation process.
Check the signature and timestamp before accepting an event, then protect against replay.
Send and retain only what the use case, policy and applicable requirements need.
Do not expose privileged credentials or signing secrets in browsers and mobile clients.
Use short-lived access and permissions appropriate to sensitive documents and results.
Use identifiers and redaction so operational logs remain useful without becoming a shadow database.
API availability alone does not reveal delayed decisions, failing webhooks or customers stuck in an unresolved state.
Rate, latency and status by endpoint.
Delivery, delay, retries and dead letters.
Resources pending longer than expected.
Provider timeouts and fallback activity.
Completion, action required and drop-off.
A useful sandbox should cover deterministic outcomes, but integration testing must also simulate timing, duplication and partial failure.
Required fields, optional fields, enums, status transitions and version handling.
Confirm that network retries do not create duplicate applications or checks.
Verify signatures, redelivery, deduplication and out-of-order handling.
Confirm retry limits, customer status and operational alerts.
Names, addresses, scripts, document types and business structures.
Ensure the client can recover state without restarting completed work.
Validate one journey and its failure modes before connecting every product, market and downstream consumer.
Identify commands, resources, states, events and owners.
Agree payloads, identifiers, errors and version policy.
Create an application, consume events and retrieve outcomes.
Exercise retries, duplicates, delays and interrupted journeys.
Observe bounded traffic and expand after operational validation.
This page owns technical integration. The related pages cover process design, runtime routing and specific verification capabilities.
Bring your current journey, data model and downstream systems. Ondorse can help identify the resources, events and failure behaviours needed for a reliable implementation.