Verifiziere einen Nutzer oder ein Unternehmen einmal. Teile das Ergebnis mit einem Partner, dieser onboardet dieselbe Person sofort. Kein zweiter Flow, kein zweites Selfie. Funktioniert für KYC und KYB. Entwickelt für Banking-as-a-Service, Multi-Brand-Gruppen, Embedded Finance und Marktplätze mit Sub-Plattformen.
Robinhood Ventures
Für Partner-Ökosysteme entwickelt
Dein Nutzer verifiziert sich einmal in deiner App. Dein Partner, dein BaaS-Sponsor, deine Schwestermarke, dein nachgelagerter Marktplatz, benötigt denselben Datensatz. Sende ihm einen einmaligen Share-Token. Er löst ihn ein und übernimmt die vollständige Verifizierung. Der Nutzer sieht nie einen zweiten Flow.
Wähle eine abgeschlossene Verifizierung, genehmigt, abgelehnt oder in Prüfung, und fordere von Didit einen Share-Token an. Der Token läuft standardmäßig nach einer Stunde ab; du kannst die Gültigkeit von einer Minute bis zu einem ganzen Tag festlegen.
Übergib den Token deinem Partner über dein eigenes Backend, per Webhook, Queue oder REST-Call. Der Token funktioniert nur für den Partner, den du beim Erstellen benannt hast. Niemand sonst kann ihn einlösen.
Dein Partner löst den Token ein und wählt, wie der Nutzer onboardet werden soll, vertraue deiner Entscheidung und genehmige sofort, oder übernimm die Rohdaten und lass das Compliance-Team deines Partners entscheiden.
Didit klont den gesamten Datensatz, Dokumente, Selfie, Gesichtsabgleich, AML, Registerdaten, UBOs, in den Workspace deines Partners. Dieselbe Struktur wie eine frische Verifizierung, mit einem klaren Audit-Trail zurück zum Original.
POST /v3/session/[id]/share/
POST /v3/session/import-shared/
Sofort-Onboarding · oder eigene Prüfung
session_kind: user | business
Nutzer · KYC
Unternehmen · KYB
Eine Verifizierung für viele Zwecke
Nur abgeschlossene · idempotent · audit-fähig
$ curl -X POST https://verification.didit.me/v3/session/$SID/share/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"for_application_id": "partner-app-uuid",
"ttl_in_seconds": 3600
}'{ "share_token": "eyJhbGciOi…" }$ curl -X POST https://verification.didit.me/v3/session/import-shared/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"share_token": "eyJhbGciOi…",
"workflow_id": "wf_partner_kyc",
"vendor_data": "partner-user-42",
"trust_review": true
}'{ "status": "Approved", "session_kind": "user" }# Didit B2B Reusable KYC — partner-to-partner KYC sharing
You are integrating Didit's B2B Reusable Know Your Customer (KYC) into <my_stack>. The recipe is server-to-server: one Didit application (Service X) mints a short-lived JSON Web Token (JWT) share token for a finished session; a partner Didit application (Service Y) imports the token and Didit clones the full verified session into Service Y. Works for both KYC and Know Your Business (KYB) sessions.
Built for Banking-as-a-Service (BaaS) sponsor banks, multi-brand financial groups, embedded finance through partner banks, marketplaces with regional or vertical sub-platforms, on-ramp + exchange ecosystems, white-label resellers, and B2B KYB consortia where the same legal entity onboards once and serves many. Every URL, header, and enum value below is canonical — do not paraphrase or "improve" them.
## 1. Provision both applications
- Sign up: https://business.didit.me (no credit card required).
- Or provision programmatically: POST https://apx.didit.me/auth/v2/programmatic/register/
- Create TWO applications in your Didit organisation. One acts as Service X (mints share tokens), the other as Service Y (imports them). In production these will usually live in different organisations — one per partner.
- Each application has its own `x-api-key`. Service X uses its own key to mint; Service Y uses its own key to import.
## 2. Service X — mint a share token
Service X picks a finished session it owns and posts to the share endpoint:
POST https://verification.didit.me/v3/session/{sessionId}/share/
Headers:
x-api-key: <Service X api key>
Content-Type: application/json
Body:
{
"for_application_id": "<partner-application-uuid>",
"ttl_in_seconds": 3600
}
Bounds on `ttl_in_seconds`: min 60, max 86400, default 3600.
Requirements:
- The session must be in a FINISHED status: "Approved", "Declined", or "In Review".
- The API key must hold the `write:sessions` privilege.
- `for_application_id` must be a real Didit application uuid — usually the partner's app.
Response: 201 Created with the JWT in the `share_token` field plus `for_application_id` and `session_kind` ("user" or "business" — Didit detects this from the source session and embeds it in the token):
{
"share_token": "eyJhbGciOiJIUzI1NiJ9...",
"for_application_id": "partner-app-uuid",
"session_kind": "user"
}
## 3. Transmit the token to Service Y
Service X transmits the `share_token` to Service Y over a pre-arranged backend channel — REST, message queue, signed webhook, anything you control. The token is scoped to Service Y's application and useless to any other application.
## 4. Service Y — import the shared session
Service Y posts the token to the import endpoint:
POST https://verification.didit.me/v3/session/import-shared/
Headers:
x-api-key: <Service Y api key>
Content-Type: application/json
Body:
{
"share_token": "<jwt from step 2>",
"workflow_id": "<Service Y's own workflow id>",
"vendor_data": "<Service Y's internal user id>",
"trust_review": true
}
`trust_review`:
- `true` → the imported session preserves the original status ("Approved" / "Declined" / "In Review"). Service Y onboards the user instantly. Use when Service Y fully trusts Service X's decision (sister brand, regulated partner with a signed data-sharing agreement).
- `false` → the imported session lands in "In Review" so Service Y's compliance team makes its own call. Safe default for new partner relationships.
Response: 201 Created with a brand-new session in Service Y's application:
{
"session_id": "<new uuid>",
"session_number": <int>,
"session_kind": "user" | "business",
"status": "Approved" | "In Review" | "Declined",
"shared_from_session": "<original session uuid in Service X>",
"vendor_data": "<Service Y's internal user id>",
"id_verifications": [...],
"liveness_checks": [...],
"face_matches": [...],
"aml_screenings": [...],
"database_validations": [...],
"proof_of_address": [...],
"phone_verifications": [...],
"email_verifications": [...]
}
For a `session_kind: "business"` token Didit clones the KYB shape instead. KYB session statuses are UPPER_SNAKE_CASE (not Title Case like KYC):
{
"session_id": "<new uuid>",
"session_kind": "business",
"status": "APPROVED",
"shared_from_session": "<original business session uuid>",
"vendor_data": "<Service Y's internal business id>",
"registry_checks": [...],
"key_people_checks": [...],
"document_verifications": [...],
"aml_screenings": [...],
"questionnaires": [...]
}
A new User or Business entity is auto-created in Service Y if one with the supplied `vendor_data` doesn't already exist.
## 5. Idempotency, expiration, errors
| Status | Reason |
|--------|--------|
| 401 | Share token invalid or past `exp` — request a new one. |
| 403 | Token not intended for your application, OR session already imported into your app. |
| 404 | Original session no longer exists. |
| 404 | `workflow_id` not found in your application. |
The duplicate-import check is enforced against the (share_token, partner application) pair.
## 6. Webhooks (optional, only when Service Y wants async updates)
Service Y can register a webhook destination once via:
POST https://verification.didit.me/v3/webhook/destinations/
Body: url, subscribed_events: ["status.updated"]
Every webhook delivery carries an `X-Signature-V2` header you MUST verify before trusting the payload. HMAC-SHA256 verification MUST run against the raw body bytes (the raw payload as Didit sent it) BEFORE any JSON parsing — re-serialising the parsed body changes whitespace and key order, which invalidates the signature.
Algorithm:
1. sortKeys(payload) recursively
2. shortenFloats (truncate trailing zeros after the decimal point)
3. JSON.stringify the result
4. HMAC-SHA256 with the secret_shared_key
5. Hex-encode, compare to the X-Signature-V2 header.
## 7. Hard rules — do not change
- Base URL for /v3/* endpoints is verification.didit.me (NOT apx.didit.me).
- Auth header is x-api-key (lowercase, hyphenated).
- Webhook signature header is X-Signature-V2 (NOT X-Signature).
- Status casing matches exactly: "Approved", "Declined", "In Review", "Not Finished" (Title Case With Spaces — KYC convention).
- session_kind is lowercase: "user" or "business".
- The share API is BUSINESS-to-BUSINESS sharing. Service X and Service Y are responsible for the data-sharing legal basis under General Data Protection Regulation (GDPR), UK GDPR, and any cross-border transfer rules. Didit ships the technical capability; you ship the data-sharing agreement.
## 8. Pricing reference (public)
- Service X already paid for the original verification (full KYC bundle is $0.30 or KYB session starts at $2.00; see didit.me/pricing).
- Service Y pays nothing on the import side — `POST /v3/session/import-shared/` is included with every plan.
- 500 free verifications every month on every account (applies to fresh captures, not imports).
## 9. Verify your integration
- Sandbox starts on signup at https://business.didit.me — no separate flag.
- Create two sandbox applications: one as Service X (issuer), the other as Service Y (importer). Use Service X's API key to mint a token for a finished sandbox session, hand the token off, use Service Y's API key to import.
- Switch to live: flip each application's environment toggle in console.
When in doubt:
- https://docs.didit.me/sessions-api/share-session/overview
- https://docs.didit.me/sessions-api/share-session/share
- https://docs.didit.me/sessions-api/share-session/import
- https://docs.didit.me/core-technology/reusable-kyc/share-kyc-via-api
$0 / Monat. Keine Kreditkarte erforderlich.
Zahle nur, was du nutzt. Über 25 Module. Öffentliche Preise pro Modul, keine monatliche Mindestgebühr.
Individuelle MSA & SLA. Für große Volumina und regulierte Programme.
Kostenlos starten → nur zahlen, wenn eine Prüfung läuft → Enterprise für einen individuellen Vertrag, SLA oder Datenresidenz freischalten.
Didit ist die Infrastruktur für Identität und Betrug, die Plattform, die wir uns gewünscht hätten, als wir selbst Produkte entwickelten: offen, flexibel und entwicklerfreundlich, sodass sie als echter Bestandteil deines Stacks funktioniert, anstatt einer Blackbox, um die herum du integrieren musst.
Eine API deckt die Verifizierung von Personen (KYC, Know Your Customer), Unternehmen (KYB, Know Your Business), das Screening von Krypto-Wallets (KYT, Know Your Transaction) und die Echtzeit-Überwachung von Transaktionen ab, auf einem Stack, der darauf ausgelegt ist,:
Die zugrunde liegende Basis: über 14.000 Dokumententypen in über 48 Sprachen, über 1.000 Datenquellen und über 200 Betrugssignale bei jeder Session. Die Didit-Infrastruktur lernt dynamisch aus jeder Session und wird täglich besser.
B2B Reusable KYC ermöglicht es einem Unternehmen, einen verifizierten Nutzer oder ein Unternehmen an ein anderes Unternehmen zu übergeben, sodass der Partner dieselbe Person onboarden kann, ohne die Verifizierung erneut durchzuführen.
Es funktioniert in zwei Schritten:
Dein Partner wählt die Onboarding-Geschwindigkeit. Vertraue deiner Entscheidung und genehmige den Nutzer sofort, oder ziehe die Rohdaten und lasse das Compliance-Team deines Partners die Entscheidung treffen.
Funktioniert sowohl für Know Your Customer (KYC) als auch für Know Your Business (KYB), derselbe Aufruf, beide Formen.
Vollständige Referenz: docs.didit.me/sessions-api/share-session.
Für jedes Geschäftsmodell, bei dem eine Plattform einen Nutzer einmal onboardet und mehrere Partnerplattformen dieselbe Verifizierung benötigen:
Wenn du eine Datenfreigabevereinbarung mit deinem Partner abschließen kannst, liefert diese API die technische Hälfte.
Der gesamte Prozess dauert normalerweise unter 30 Sekunden von Anfang bis Ende, Ausweis nehmen, Dokument fotografieren, Selfie machen, fertig. Das ist der schnellste auf dem Markt. Herkömmliche KYC-Anbieter benötigen für denselben Prozess in der Regel mehr als 90 Sekunden.
Im Backend liefert Didit das Ergebnis in unter zwei Sekunden bei p99, gemessen vom Moment, in dem der Nutzer das Selfie beendet, bis zum Auslösen deines Webhooks. Die mobile Erfassung ist für langsame Telefone und langsame Netzwerke optimiert: progressive Bildkomprimierung, verzögertes Laden des Software Development Kits und eine One-Tap-Übergabe vom Desktop zum Telefon per QR-Code, wenn der Nutzer im Web beginnt.
POST /v3/session/import-shared/ gibt 201 Created zurück mit einer brandneuen Session in deiner Anwendung, frische session_id und session_number, vollständige Payload vom Ursprung geklont.
Wichtige Felder:
status, Approved / Declined / In Review (beibehalten, wenn trust_review: true, auf In Review gesetzt, wenn trust_review: false).session_kind, user (KYC) oder business (KYB).shared_from_session, verweist auf die ursprüngliche Session in der Quellanwendung. Kanonisches Signal, dass diese Session importiert und nicht frisch erfasst wurde.vendor_data, die interne Benutzer- / Geschäfts-ID, die DU beim Importaufruf übergeben hast.id_verifications, liveness_checks, face_matches, aml_screenings, database_validations, proof_of_address, location_checks, phone_verifications, email_verifications.registry_checks, key_people_checks (mit ihren verschachtelten KYCs), document_verifications, aml_screenings, questionnaires.Identische Form wie eine frische Session, dein bestehender Webhook-Handler liest sie auf dieselbe Weise.
Jede Session landet in einem von sieben klaren Status, sodass dein Code immer weiß, was zu tun ist:
Approved, alle Prüfungen bestanden. Führe den Nutzer weiter.Declined, eine oder mehrere Prüfungen fehlgeschlagen. Du kannst dem Nutzer erlauben, den spezifischen fehlgeschlagenen Schritt (z.B. das Selfie erneut aufnehmen) erneut einzureichen, ohne den gesamten Prozess neu zu starten.In Review, zur Compliance-Prüfung markiert. Öffne den Fall in der Konsole, sieh dir alle Signale an, entscheide über Genehmigung oder Ablehnung.In Progress, der Nutzer befindet sich mitten im Prozess.Not Started, Link gesendet, Nutzer hat ihn noch nicht geöffnet. Sende eine Erinnerung, wenn er zu lange unbeachtet bleibt.Abandoned, Nutzer hat den Link geöffnet, aber nicht rechtzeitig abgeschlossen. Erneut ansprechen oder ablaufen lassen.Expired, der Session-Link ist abgelaufen. Erstelle eine neue Session.Ein signierter Webhook wird bei jeder Statusänderung ausgelöst, sodass deine Datenbank immer synchron bleibt. Abgebrochene und abgelehnte Sessions sind kostenlos.
Produktionsdaten werden standardmäßig in der Europäischen Union verarbeitet und gespeichert, auf Amazon Web Services. Unternehmenskunden können alternative Regionen für Jurisdiktionen anfordern, deren Regulierungsbehörden dies verlangen.
Verschlüsselung überall. AES-256 im Ruhezustand über jede Datenbank, jeden Objektspeicher und jedes Backup. Transport Layer Security 1.3 während der Übertragung bei jedem API-Aufruf, Webhook und jeder Business Console-Session. Biometrische Daten werden unter einem separaten Customer Master Key verschlüsselt.
Die Aufbewahrung liegt in deiner Hand. Die Standardaufbewahrungsfrist ist unbegrenzt, es sei denn, du konfigurierst eine kürzere, zwischen 30 Tagen und 10 Jahren pro Anwendung, und du kannst jede einzelne Session jederzeit über das Dashboard oder die API löschen.
Zertifizierungen: SOC 2 Typ 1 (Typ 2 Audit läuft), ISO/IEC 27001:2022, iBeta Level 1 PAD und eine öffentliche Bestätigung von Spaniens Tesoro / SEPBLAC / CNMV, dass Didits Fernidentitätsprüfung sicherer ist als die persönliche Verifizierung. Vollständiger Bericht unter /security-compliance.
Didit ist standardmäßig konform mit den für die Identitätsinfrastruktur relevanten Regulierungsbehörden:
Ausführliches Memo, alle Zertifikate, alle Schreiben der Regulierungsbehörden: /security-compliance.
Drei Integrationswege, wähle den, der am besten zu deinem Stack passt:
Das gleiche Dashboard, die gleiche Abrechnung, der gleiche Pay-per-Success-Preis für alle drei Optionen. Eine Schritt-für-Schritt-Anleitung findest du unter docs.didit.me/integration/integration-prompt.
Eine API für KYC, KYB, Transaktionsüberwachung und Wallet-Screening. In 5 Minuten integriert.