Share KYC via API

How It Works

Let's assume a user A passed user verification in Service X and is now registering at the partner Service Y. If Service X agrees to share the information about A with Service Y, it can be done as follows:

Generate Share Token (Service X): Service X makes an API call to generate a secure, short-lived share_token for a specific user's verification session. This token is designated for use by Service Y only. See API Reference: Share Session API.
Pass Token to Partner (Service X -> Service Y): Service X securely transmits the generated share_token to Service Y through a pre-arranged backend channel.
Import Session (Service Y): Service Y uses the received share_token to make an API call to import the user's data. This creates a complete copy of the verification session, including all documents and checks, within Service Y's own environment. See API Reference: Import Shared Session API.

Import Options

When importing a session, Service Y has control over how to handle the results:

trust_review: This boolean parameter determines if Service Y trusts the review and final status (Approved/Declined) from Service X.
- true: The session is copied with the original status. The user is instantly onboarded (or rejected) on Service Y.
- false: The session data is copied, but the status is automatically set to In Review. This allows Service Y to use the collected documents and data but perform its own internal review process to make a final decision.
workflow_id: Service Y must specify which of its own verification workflows to associate with the imported session.
vendor_data: Service Y can assign its own internal user identifier to the imported session.

Important Considerations

Finished Sessions Only: A share token can only be generated for sessions that have a finished status (Approved, Declined, In Review).
No Duplicates: A specific session can only be imported once into a given partner application. Subsequent attempts will be rejected.

Reusable KYC vs. Share KYC via API

While both features facilitate identity reuse, they serve different purposes:

Feature	User-Controlled Reusable KYC	Share KYC via API (B2B Sharing)
Who initiates?	The end-user, during onboarding.	The business, via a server-to-server API call.
Consent	User explicitly consents to share their data for each reuse.	Consent is typically handled in the user's terms of service with the initial business. A clear data sharing agreement between partner businesses is required.
Data Flow	User's Didit ID facilitates data sharing directly with the new app.	`Service X` shares data with `Service Y` via a secure token.
Use Case	A user wanting to quickly sign up for multiple, unrelated services.	Partner ecosystems, financial services groups, or conglomerates where a user's identity needs to be portable across related platforms.

❗️ Important: Data Sharing Restrictions

Sharing personal user data between different organizations is subject to strict legal and regulatory requirements. Before using this feature, your organization is responsible for ensuring you are fully compliant with all applicable data protection laws, such as GDPR in the European Union and UK GDPR in the United Kingdom.

You must:

Establish a Legal Basis: Ensure you have a legitimate legal basis for sharing the data. This often requires a clear data sharing agreement between you and your partner organization.

Ensure User Consent: Confirm that your users have been properly informed and have consented to their data being shared with your partners, as outlined in your terms of service and privacy policy.

Handle International Transfers Appropriately: If data is being transferred across borders (e.g., from the EU to a non-EU country), you must ensure appropriate safeguards are in place as required by law.

Didit provides the technical capability for data sharing, but your organization and your partners are solely responsible for all legal and compliance obligations related to the data you share. We strongly recommend consulting with your legal counsel before implementing this feature.