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

# Partilhar KYC via API: Verificação reutilizável

> Partilhe dados de verificação via API com a Didit. Elimine KYC repetidos entre parceiros através de tokens de partilha temporários.

## Como funciona

Suponhamos que um utilizador `A` passou na verificação de utilizadores no `Service X` e está agora a registar-se no parceiro `Service Y`. Se o `Service X` concordar em partilhar as informações sobre `A` com o `Service Y`, tal pode ser feito da seguinte forma:

1. **Gerar token de partilha (`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 utilizador específico. Este token destina-se a ser utilizado apenas pelo `Service Y`. Consulte a Referência da API: [Share Session API](https://docs.didit.me/pt/sessions-api/share-session/share.md).

2. **Passar o token ao parceiro (`Service X` -> `Service Y`)**: O `Service X` transmite de forma segura o `share_token` gerado para o `Service Y` através de um canal de backend previamente acordado.

3. **Importar sessão (`Service Y`)**: O `Service Y` utiliza o `share_token` recebido para fazer uma chamada de API a fim de importar os dados do utilizador. Isto cria uma cópia completa da sessão de verificação, incluindo todos os documentos e verificações, no próprio ambiente do `Service Y`. Consulte a Referência da API: [Import Shared Session API](https://docs.didit.me/pt/sessions-api/share-session/import.md).

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

Ao importar uma sessão, o `Service Y` tem controlo sobre como processar os resultados:

* **`trust_review`**: Este parâmetro booleano determina se o `Service Y` confia na revisão e no estado final (`Approved`/`Declined`) do `Service X`.
  * `true`: A sessão é copiada com o estado original. O utilizador é integrado instantaneamente (ou rejeitado) no `Service Y`.
  * `false`: Os dados da sessão são copiados, mas o estado é automaticamente definido como `In Review`. Isto permite ao `Service Y` utilizar os documentos e dados recolhidos, mas realizar o seu próprio processo de revisão interna para tomar uma decisão final.
* **`workflow_id`**: O `Service Y` tem de especificar qual dos seus próprios fluxos de verificação deve associar à sessão importada.
* **`vendor_data`**: O `Service Y` pode atribuir o seu próprio identificador interno de utilizador à sessão importada.

### Considerações importantes

* **Apenas sessões finalizadas**: Um token de partilha só pode ser gerado para sessões que tenham um estado finalizado (`Approved`, `Declined`, `In Review`).
* **Sem duplicados**: Uma sessão específica só pode ser importada uma vez numa determinada aplicação parceira. Tentativas subsequentes serão rejeitadas.

***

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

Embora ambas as funcionalidades facilitem a reutilização de identidade, servem finalidades diferentes:

| Funcionalidade | KYC reutilizável controlado pelo utilizador | Partilha de KYC via API (partilha B2B) |
| - | - | - |
| **Quem inicia?** | O utilizador final, durante o onboarding. | A empresa, através de uma chamada de API servidor a servidor. |
| **Consentimento** | O utilizador consente explicitamente na partilha dos seus dados para cada reutilização. | O consentimento é normalmente tratado nos termos de serviço que o utilizador aceita com a empresa inicial. É necessário um acordo claro de partilha de dados entre as empresas parceiras. |
| **Fluxo de dados** | O Didit ID do utilizador facilita a partilha de dados diretamente com a nova aplicação. | O `Service X` partilha dados com o `Service Y` através de um token seguro. |
| **Caso de utilização** | Um utilizador que pretende registar-se rapidamente em múltiplos serviços não relacionados. | Ecossistemas de parceiros, grupos de serviços financeiros ou conglomerados onde a identidade de um utilizador precisa de ser transferível entre plataformas relacionadas. |

***

> ## ❗️ Importante: Restrições à partilha de dados
>
> A partilha de dados pessoais de utilizadores entre diferentes organizações está sujeita a requisitos legais e regulamentares rigorosos. Antes de utilizar esta funcionalidade, a sua organização é responsável por garantir a total conformidade com todas as leis de proteção de dados aplicáveis, tais como o RGPD na União Europeia e o UK GDPR no Reino Unido.
>
> Deve:
>
> 1. **Estabelecer uma base jurídica**: Garantir que dispõe de uma base jurídica legítima para partilhar os dados. Isto exige frequentemente um acordo claro de partilha de dados entre si e a organização parceira.
> 2. **Garantir o consentimento do utilizador**: Confirmar que os seus utilizadores foram devidamente informados e consentiram na partilha dos seus dados com os seus parceiros, conforme delineado nos seus termos de serviço e na sua política de privacidade.
> 3. **Gerir transferências internacionais de forma adequada**: Se os dados forem transferidos além-fronteiras (por exemplo, da UE para um país fora da UE), deve garantir que são implementadas salvaguardas adequadas, conforme exigido por lei.
>
> A Didit fornece a capacidade técnica para a partilha de dados, mas a sua organização e os seus parceiros são os únicos responsáveis por todas as obrigações legais e de conformidade relacionadas com os dados que partilha. Recomendamos vivamente que consulte a sua assessoria jurídica antes de implementar esta funcionalidade.


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