Pular para o conteúdo principal
Um plugin Flutter multiplataforma que encapsula os SDKs nativos de iOS e Android e oferece uma API Dart unificada para verificação de identidade.

Repositório no GitHub

Veja o código-fonte e exemplos no GitHub

Pacote no pub.dev

didit_sdk

SDK nativo: esta é a abordagem recomendada para apps Flutter. O SDK encapsula os SDKs nativos de iOS e Android por meio de platform channels, para oferecer a melhor experiência ao usuário, gerenciamento otimizado da câmera e suporte completo a NFC.


Requisitos

Requisitos de plataforma

O consentimento biométrico requer o SDK nativo 4.10.0 ou posterior. Para pessoas abrangidas pelas leis de Illinois, Texas ou Colorado, a Didit pode solicitar consentimento biométrico explícito antes da primeira captura facial. Uma versão do SDK para Flutter que fixa os SDKs nativos de iOS e Android na versão 4.10.0 ou posterior exibe essa etapa. Versões anteriores não conseguem exibir a etapa: as sessões funcionam como antes, e a decisão informa que o consentimento não foi coletado (biometric_consent.reason: "BIOMETRIC_CONSENT_UNSUPPORTED_SDK"). Atualize se você verifica pessoas nesses estados.

Instalação

Ou adicione-o manualmente ao seu pubspec.yaml:
Em seguida, execute:

Variantes do SDK nativo

O didit_sdk inclui o SDK nativo completo. Para distribuir um binário menor, use como dependência um pacote de variante. Ele expõe exatamente a mesma API Dart e fixa o SDK nativo correspondente nas duas plataformas:
Use como dependência exatamente um desses pacotes e faça os imports a partir do pacote escolhido, por exemplo package:didit_sdk_core/sdk_flutter.dart.

Configuração no iOS

O plugin é compatível com os dois gerenciadores de dependências do Flutter para iOS: Swift Package Manager e CocoaPods.

Swift Package Manager

Se a sua versão do Flutter tiver o suporte ao Swift Package Manager ativado (ative com flutter config --enable-swift-package-manager no Flutter 3.24+), o plugin é usado automaticamente como um pacote Swift. Nenhuma configuração no Podfile é necessária: a dependência nativa DiditSDK é resolvida a partir do GitHub por conta própria. Defina o deployment target de iOS do seu app no Xcode (target do Runner e projeto) com o mínimo exigido pelo pacote escolhido: 15.0 para didit_sdk e didit_sdk_nfc, 13.0 para didit_sdk_core e didit_sdk_autodetection.

CocoaPods

Com o didit_sdk, o plugin seleciona a variante do SDK nativo de iOS a partir de $DiditSdkIosVariant, uma variável global Ruby que você define no ios/Podfile do seu app (o pod DiditSDK não está no trunk do CocoaPods):
Se você usa um pacote de variante (didit_sdk_core, didit_sdk_autodetection, didit_sdk_nfc), ele fixa diretamente o seu subspec nativo e ignora $DiditSdkIosVariant. Mantenha a linha pod e o deployment target do seu Podfile de acordo com essa variante (por exemplo, pod 'DiditSDK/Core', :podspec => ... com platform :ios, '13.0').
As variantes all e nfc exigem deployment target iOS 15.0+; core e autodetection podem usar iOS 13.0. Ao trocar de variante, limpe o CocoaPods antes (rm -rf Pods Podfile.lock) para que a variante anterior do SDK não seja reutilizada.
A tag na URL do podspec deve corresponder à versão do SDK nativo de iOS fixada pela sua versão do didit_sdk (4.9.1 fixa o SDK nativo 4.9.1). Se a URL apontar para uma tag mais antiga, o pod install não consegue resolver a dependência: o CocoaPods encontra um podspec que declara essa versão mais antiga, enquanto o plugin exige uma correspondência exata. Ao atualizar o didit_sdk, altere a tag nessa URL para a mesma versão.

Configuração no Android

Por padrão, o plugin depende do SDK completo para Android, incluindo NFC. Para compilar sem NFC, adicione isto ao android/gradle.properties:
Isso troca a dependência de me.didit:didit-sdk para me.didit:didit-sdk-core, removendo o módulo de leitura por NFC e as suas dependências JMRTD/SCUBA/BouncyCastle. Quando o NFC está ativado (padrão), adicione esta regra de empacotamento ao android/app/build.gradle.kts para resolver um arquivo de metadados duplicado do BouncyCastle:
Sem essa regra, a compilação falha com um erro mergeDebugJavaResource. A regra não é necessária quando diditSdkAndroidNfcEnabled=false.
O SDK nativo para Android é resolvido a partir de um repositório Maven remoto no GitHub (desde o plugin 3.4.0), e nenhuma configuração manual do Maven é necessária no seu app.

Permissões

iOS

Adicione as seguintes chaves ao Info.plist do seu app:
Se faltar alguma chave de privacidade obrigatória do iOS, o iOS encerra o app assim que o SDK tenta acessar o recurso protegido correspondente. Por exemplo, a ausência de NSCameraUsageDescription causa uma falha quando o usuário toca no botão de tirar foto da câmera de documentos.

Configuração de NFC

Para habilitar a leitura NFC de passaportes e documentos de identidade com chip:
  1. Adicione a capability de NFC no Xcode:
    • Selecione o seu target > Signing & Capabilities > + Capability > Near Field Communication Tag Reading
  2. Adicione os identificadores ISO7816 ao Info.plist:
D392F000260100000001 permite que o SDK leia o My Number Card do Japão por meio do JPKI: sem ele, o iOS não informa o cartão ao SDK. A leitura do My Number Card ainda não está habilitada em produção, e o identificador não altera nada para outros documentos, então você já pode adicioná-lo.
  1. Adicione um arquivo de entitlements com a leitura de tags NFC habilitada:
Verifique se o provisioning profile do app inclui a capability NFC Tag Reading. Se o bundle ID não estiver configurado para NFC na sua conta Apple Developer, o Xcode vai falhar na assinatura do app por falta do entitlement com.apple.developer.nfc.readersession.formats. Essa configuração de NFC não é necessária para as variantes core ou autodetection ($DiditSdkIosVariant), nem para os pacotes didit_sdk_core / didit_sdk_autodetection, pois nenhum deles lê chips.

Android

As seguintes permissões são declaradas no AndroidManifest.xml do SDK e mescladas automaticamente: Os recursos de hardware de câmera e NFC são declarados como opcionais (android:required="false"), para que o seu app possa ser instalado em dispositivos sem esses recursos. Quando diditSdkAndroidNfcEnabled=false, o SDK não adiciona a permissão nem o recurso de NFC do Android.

Permissões em tempo de execução

O SDK trata automaticamente as solicitações de permissão em tempo de execução do Android. Quando o usuário chega a uma etapa que exige acesso à câmera:
  1. O SDK solicita a permissão de câmera, caso ela ainda não tenha sido concedida
  2. Se o usuário negar a permissão, uma mensagem de erro é exibida com um botão Try Again
  3. Se o usuário conceder a permissão, o fluxo de verificação continua
Você não precisa solicitar a permissão de câmera no código do seu app antes de chamar startVerification(): o SDK cuida disso internamente.

Início rápido


Métodos de integração

O SDK oferece dois métodos de integração:

Método 1: token de sessão (recomendado para produção)

Crie uma sessão no seu backend usando a API Create Verification Session e, em seguida, passe o token para o SDK:
Essa abordagem oferece controle total sobre:
  • A associação das sessões aos seus usuários (vendor_data)
  • A definição de metadados personalizados
  • A configuração de callbacks por sessão

Método 2: ID do fluxo (integração mais simples)

Em integrações mais simples, o SDK pode criar sessões diretamente usando o ID do seu fluxo de verificação (workflow), sem necessidade de backend:
Os parâmetros avançados de sessão (contact_details, expected_details, metadata) são suportados somente pelo método de token de sessão, em que o seu backend chama a API Create Session com suporte a todos os parâmetros. Passe o session_token retornado para DiditSdk.startVerification().

Configuração

Personalize o comportamento do SDK passando um objeto DiditConfig:
Em startVerificationWithWorkflow, passe config como parâmetro nomeado:

Opções de configuração

Opções de câmera

As opções de câmera correspondem às opções de câmera do Web SDK. Cada lente é CameraLens.front ou CameraLens.back. Se o dispositivo não tiver a lente solicitada, o SDK usa a primeira câmera disponível. O alternador de câmera também fica oculto em dispositivos que têm apenas uma câmera. Defina uma opção de alternador como false para fixar o usuário na lente padrão daquela etapa.
Temas e cores: cores, fundos e as configurações da tela de introdução são definidos nas suas configurações de White Label no Didit Console, e não na configuração do SDK. Isso garante uma identidade visual consistente em todas as plataformas.

Suporte a idiomas

O SDK oferece suporte a 54 idiomas. Se nenhum idioma for especificado, o SDK usa a configuração regional do dispositivo, com inglês como alternativa.
Ver todos os idiomas compatíveis →

Parâmetros avançados de sessão

Parâmetros como contact_details, expected_details e metadata são aceitos somente pelo método de token de sessão. Seu backend chama POST /v3/session/ com suporte completo a parâmetros e, em seguida, passa o session_token retornado para o SDK.
O método Dart startVerificationWithWorkflow aceita apenas workflowId, vendorData e config. Versões anteriores à 3.4.0 expunham os parâmetros contactDetails, expectedDetails e metadata, mas eles foram removidos porque o endpoint Unilink não os aceita.

Tratamento de resultados

Tanto startVerification quanto startVerificationWithWorkflow retornam um Future<VerificationResult>. O resultado é uma classe selada: use pattern matching para identificar o desfecho.

Casos de resultado

Propriedades de SessionData

Tipos de erro

O enum VerificationErrorType expõe os seguintes casos:

Perda de conexão

Se o dispositivo perder a conexão durante a verificação, o SDK exibe uma tela de “Sem conexão com a internet” em vez de deixar uma etapa carregando. Ele continua verificando em segundo plano e fecha a tela sozinho assim que a Didit volta a ficar acessível, e o usuário continua a partir da etapa em que estava. A tela oferece Tentar novamente e, a menos que o botão de fechar esteja desativado, Sair da verificação. Sair encerra a verificação com um resultado VerificationFailed cujo tipo de erro é networkError, para que seu app saiba que o usuário saiu devido à perda de conexão.

Exemplo completo de tratamento de resultados


Exemplo de ponta a ponta (sessão no backend → Flutter SDK → webhook)

A integração pronta para produção: seu backend cria a sessão, seu app Flutter recebe o session_token e o SDK executa o fluxo. A decisão final é entregue ao seu backend via webhook. Nunca confie apenas no resultado do lado do cliente.

1. Backend: criar a sessão

2. Flutter: trocar o token e iniciar o SDK

3. Backend: receber a decisão final via webhook

Consulte o guia de webhooks para ver os detalhes da verificação de assinatura HMAC.

Exemplo completo


Última modificação em 1 de novembro de 2026