Pular para o conteúdo principal

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

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:

❗️ 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.
Última modificação em 1 de novembro de 2026