> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# KYC per API teilen: Wiederverwendbare Verifizierung

> Verifizierungsdaten sicher per API teilen: Didit verhindert doppelte KYCs über integrierte Dienste hinweg mit kurzlebigen Share-Tokens.

## Wie es funktioniert

Nehmen wir an, ein Benutzer `A` hat die Benutzerverifizierung in `Service X` erfolgreich durchlaufen und registriert sich nun beim Partner `Service Y`. Wenn `Service X` zustimmt, die Informationen über `A` mit `Service Y` zu teilen, kann dies wie folgt ablaufen:

1. **Share-Token generieren (`Service X`)**: `Service X` ruft die API auf, um ein sicheres, kurzlebiges `share_token` für die Verifizierungssitzung eines bestimmten Benutzers zu generieren. Dieses Token ist ausschließlich für die Verwendung durch `Service Y` bestimmt. Siehe API-Referenz: [Share Session API](https://docs.didit.me/de/sessions-api/share-session/share.md).

2. **Token an Partner übergeben (`Service X` -> `Service Y`)**: `Service X` überträgt das generierte `share_token` sicher über einen vorab vereinbarten Backend-Kanal an `Service Y`.

3. **Sitzung importieren (`Service Y`)**: `Service Y` verwendet das erhaltene `share_token`, um über einen API-Aufruf die Benutzerdaten zu importieren. Dadurch wird eine vollständige Kopie der Verifizierungssitzung einschließlich aller Dokumente und Prüfungen in der eigenen Umgebung von `Service Y` erstellt. Siehe API-Referenz: [Import Shared Session API](https://docs.didit.me/de/sessions-api/share-session/import.md).

### Importoptionen

Beim Importieren einer Sitzung hat `Service Y` die Kontrolle darüber, wie die Ergebnisse verarbeitet werden:

* **`trust_review`**: Dieser boolesche Parameter bestimmt, ob `Service Y` der Prüfung und dem endgültigen Status (`Approved`/`Declined`) von `Service X` vertraut.
  * `true`: Die Sitzung wird mit dem ursprünglichen Status kopiert. Der Benutzer durchläuft bei `Service Y` sofort das Onboarding (oder wird abgelehnt).
  * `false`: Die Sitzungsdaten werden kopiert, der Status wird jedoch automatisch auf `In Review` gesetzt. Dadurch kann `Service Y` die erfassten Dokumente und Daten nutzen, führt jedoch einen eigenen internen Prüfungsprozess durch, um eine endgültige Entscheidung zu treffen.
* **`workflow_id`**: `Service Y` muss angeben, welcher der eigenen Verifizierungs-Workflows mit der importierten Sitzung verknüpft werden soll.
* **`vendor_data`**: `Service Y` kann der importierten Sitzung eine eigene interne Benutzerkennung zuweisen.

### Wichtige Hinweise

* **Nur abgeschlossene Sitzungen**: Ein Share-Token kann nur für Sitzungen mit einem abgeschlossenen Status generiert werden (`Approved`, `Declined`, `In Review`).
* **Keine Duplikate**: Eine bestimmte Sitzung kann nur einmal in eine bestimmte Partneranwendung importiert werden. Nachfolgende Versuche werden abgelehnt.

***

## Wiederverwendbares KYC vs. KYC per API teilen

Obwohl beide Funktionen die Wiederverwendung von Identitäten ermöglichen, dienen sie unterschiedlichen Zwecken:

| Funktion | Vom Benutzer gesteuertes wiederverwendbares KYC | KYC über die API teilen (B2B-Datenweitergabe) |
| - | - | - |
| **Wer initiiert?** | Der Endbenutzer während des Onboardings. | Das Unternehmen über einen Server-zu-Server-API-Aufruf. |
| **Einwilligung** | Der Benutzer willigt bei jeder Wiederverwendung ausdrücklich in die Weitergabe seiner Daten ein. | Die Einwilligung wird in der Regel in den zwischen dem Benutzer und dem ursprünglichen Unternehmen geltenden Nutzungsbedingungen geregelt. Eine eindeutige Vereinbarung zur Datenweitergabe zwischen Partnerunternehmen ist erforderlich. |
| **Datenfluss** | Die Didit-ID des Benutzers ermöglicht die direkte Datenweitergabe an die neue Anwendung. | `Service X` teilt Daten mit `Service Y` über ein sicheres Token. |
| **Anwendungsfall** | Ein Benutzer möchte sich schnell bei mehreren, voneinander unabhängigen Diensten registrieren. | Partner-Ökosysteme, Finanzdienstleistungsgruppen oder Unternehmensgruppen, bei denen die Identität eines Benutzers über verbundene Plattformen hinweg übertragbar sein muss. |

***

> ## ❗️ Wichtig: Einschränkungen bei der Datenweitergabe
>
> Die Weitergabe personenbezogener Benutzerdaten zwischen verschiedenen Organisationen unterliegt strengen gesetzlichen und regulatorischen Vorgaben. Bevor Sie diese Funktion nutzen, ist Ihre Organisation dafür verantwortlich, sicherzustellen, dass Sie alle geltenden Datenschutzgesetze vollständig einhalten, wie etwa die DSGVO in der Europäischen Union und die UK GDPR im Vereinigten Königreich.
>
> Sie müssen:
>
> 1. **Eine Rechtsgrundlage schaffen**: Stellen Sie sicher, dass Sie über eine rechtmäßige Grundlage für die Weitergabe der Daten verfügen. Dies erfordert häufig eine klare Vereinbarung zur Datenweitergabe zwischen Ihnen und Ihrer Partnerorganisation.
> 2. **Benutzereinwilligung sicherstellen**: Vergewissern Sie sich, dass Ihre Benutzer ordnungsgemäß darüber informiert wurden und eingewilligt haben, dass ihre Daten an Ihre Partner weitergegeben werden, wie in Ihren Nutzungsbedingungen und Datenschutzrichtlinien dargelegt.
> 3. **Internationale Übermittlungen angemessen handhaben**: Wenn Daten grenzüberschreitend übertragen werden (z. B. aus der EU in ein Nicht-EU-Land), müssen Sie sicherstellen, dass die gesetzlich vorgeschriebenen geeigneten Garantien vorliegen.
>
> Didit stellt die technische Möglichkeit zur Datenweitergabe bereit, Ihre Organisation und Ihre Partner tragen jedoch die alleinige Verantwortung für alle rechtlichen und regulatorischen Pflichten im Zusammenhang mit den von Ihnen geteilten Daten. Wir empfehlen dringend, vor der Implementierung dieser Funktion Ihren Rechtsbeistand zu konsultieren.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.