> ## 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.

# Compartilhar KYC via API: verificação reutilizável

> A Didit permite compartilhar dados de verificação KYC entre parceiros confiáveis via API com tokens de curta duração, evitando KYC repetido.

## Como funciona

Suponha que um usuário `A` foi aprovado na verificação de usuário no `Service X` e agora está se cadastrando no parceiro `Service Y`. Se o `Service X` concordar em compartilhar as informações sobre `A` com o `Service Y`, isso pode ser feito da seguinte forma:

1. **Gerar o token de compartilhamento (`Service X`)**: o `Service X` faz uma chamada de API para gerar um `share_token` seguro e de curta duração para a sessão de verificação de um usuário específico. Esse token se destina exclusivamente ao uso pelo `Service Y`. Consulte a referência da API: [Share Session API](https://docs.didit.me/pt-br/sessions-api/share-session/share.md).

2. **Repassar o token ao parceiro (`Service X` -> `Service Y`)**: o `Service X` transmite com segurança o `share_token` gerado ao `Service Y` por um canal de backend previamente acordado.

3. **Importar a sessão (`Service Y`)**: o `Service Y` usa o `share_token` recebido para fazer uma chamada de API que importa os dados do usuário. Isso cria uma cópia completa da sessão de verificação, incluindo todos os documentos e verificações, dentro do próprio ambiente do `Service Y`. Consulte a referência da API: [Import Shared Session API](https://docs.didit.me/pt-br/sessions-api/share-session/import.md).

### Opções de importação

Ao importar uma sessão, o `Service Y` controla como os resultados são tratados:

* **`trust_review`**: este parâmetro booleano determina se o `Service Y` confia na revisão e no status final (`Approved`/`Declined`) definidos pelo `Service X`.
  * `true`: a sessão é copiada com o status original. O usuário passa imediatamente pelo onboarding (ou é rejeitado) no `Service Y`.
  * `false`: os dados da sessão são copiados, mas o status é definido automaticamente como `In Review`. Isso permite que o `Service Y` use os documentos e dados coletados, mas realize seu próprio processo interno de revisão para tomar uma decisão final.
* **`workflow_id`**: o `Service Y` deve especificar qual dos seus próprios fluxos de verificação (workflows) será associado à sessão importada.
* **`vendor_data`**: o `Service Y` pode atribuir seu próprio identificador interno de usuário à sessão importada.

### Considerações importantes

* **Somente sessões finalizadas**: um token de compartilhamento só pode ser gerado para sessões com status finalizado (`Approved`, `Declined`, `In Review`).
* **Sem duplicatas**: uma sessão específica só pode ser importada uma vez para uma determinada aplicação parceira. Tentativas subsequentes serão rejeitadas.

***

## KYC reutilizável vs. compartilhamento de KYC via API

Embora os dois recursos facilitem a reutilização da identidade, eles atendem a propósitos diferentes:

| Recurso | KYC reutilizável controlado pelo usuário | Compartilhamento de KYC via API (compartilhamento B2B) |
| - | - | - |
| **Quem inicia?** | O usuário final, durante o onboarding. | A empresa, por meio de uma chamada de API servidor a servidor. |
| **Consentimento** | O usuário consente explicitamente com o compartilhamento dos seus dados a cada reutilização. | O consentimento normalmente é tratado nos termos de serviço aceitos pelo usuário junto à empresa inicial. É obrigatório um acordo claro de compartilhamento de dados entre as empresas parceiras. |
| **Fluxo de dados** | O Didit ID do usuário viabiliza o compartilhamento de dados diretamente com o novo app. | O `Service X` compartilha dados com o `Service Y` por meio de um token seguro. |
| **Caso de uso** | Um usuário que quer se cadastrar rapidamente em vários serviços sem relação entre si. | Ecossistemas de parceiros, grupos de serviços financeiros ou conglomerados em que a identidade do usuário precisa ser portável entre plataformas relacionadas. |

***

> ## ❗️ Importante: restrições ao compartilhamento de dados
>
> O compartilhamento de dados pessoais de usuários entre organizações diferentes está sujeito a requisitos legais e regulatórios rigorosos. Antes de usar este recurso, sua organização é responsável por garantir que esteja em total conformidade com todas as leis de proteção de dados aplicáveis, como o GDPR na União Europeia e o UK GDPR no Reino Unido.
>
> Você deve:
>
> 1. **Estabelecer uma base legal**: garanta que você tem uma base legal legítima para compartilhar os dados. Isso costuma exigir um acordo claro de compartilhamento de dados entre você e sua organização parceira.
> 2. **Garantir o consentimento do usuário**: confirme que seus usuários foram devidamente informados e consentiram com o compartilhamento dos seus dados com seus parceiros, conforme descrito nos seus termos de serviço e na sua política de privacidade.
> 3. **Tratar transferências internacionais de forma adequada**: se os dados forem transferidos entre países (por exemplo, da UE para um país fora da UE), você deve garantir que as salvaguardas adequadas estejam em vigor, conforme exigido por lei.
>
> O Didit fornece a capacidade técnica para o compartilhamento de dados, mas sua organização e seus parceiros são os únicos responsáveis por todas as obrigações legais e de conformidade relacionadas aos dados que vocês compartilham. Recomendamos fortemente consultar sua assessoria jurídica antes de implementar este recurso.


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