Visão geral
A Busca facial é uma busca biométrica 1:N: a Didit pega o maior rosto detectado na suauser_image e o procura no índice de busca facial da sua aplicação, que reúne rostos cadastrados a partir de sessões de verificação, chamadas de API avulsas salvas, envios diretos de rosto para perfis de usuário e suas listas de bloqueio e de permissão. Ela é diferente da Correspondência facial, que é 1:1: a Correspondência facial compara uma selfie com o retrato de um documento específico, enquanto a Busca facial pergunta “já vimos esta pessoa em algum lugar antes?”.
Vale entender dois comportamentos antes de interpretar o relatório:
- Somente correspondências na lista de bloqueio geram recusa.
face_search.statuséDeclinedsomente quando um avisoFACE_IN_BLOCKLISTouPOSSIBLE_FACE_IN_BLOCKLISTé disparado. Correspondências duplicadas, por si sós, retornamApproved. Analisematchesewarnings, e não apenasstatus. - Persistência e cadastro opcionais. Quando
save_api_request=true(o padrão), a chamada é persistida como uma sessão do tipo API e o rosto buscado é cadastrado no seu índice de busca facial. Rostos cadastrados por chamadas de Busca facial são excluídos dos resultados futuros da Busca facial, então buscas repetidas nunca correspondem entre si. Enviesave_api_request=falsepara uma consulta pontual: nada é armazenado e o rosto não é cadastrado.
Onde os resultados aparecem
A Busca facial é uma API avulsa. Os resultados da busca são retornados de forma síncrona, somente na resposta dePOST /v3/face-search/, como um objeto face_search no singular, no nível superior:
face_searches[] em lugar nenhum: a convenção de arrays no plural usada por id_verifications[], aml_screenings[] e liveness_checks[] no endpoint de decisão da sessão não se aplica aqui.
Quando save_api_request=true (o padrão), a chamada também é persistida como uma sessão do tipo API:
- Business Console: a sessão aparece na sua lista de sessões com a imagem usada na busca, as correspondências e os avisos.
GET /v3/session/{sessionId}/decision/: a sessão pode ser consultada usando orequest_idretornado como ID da sessão. Os dados persistidos aparecem como uma entradaFACE_SEARCHemfeatures[]e como um item deliveness_checks[]contendo asmatchesarmazenadas (com valores dematch_image_urlassinados novamente) e oswarnings, e não como um objetoface_search.
save_api_request=false, request_id é um UUID de correlação transitório: a sessão nunca é armazenada, então não pode ser consultada no Console nem no endpoint de decisão.
Esquema
Consulte Busca facial na referência de modelos de dados para ver as tabelas de campos oficiais. A estrutura abaixo reflete o que o endpoint de fato retorna em tempo de execução.matches[]é limitado a 5 entradas acima do limiar mínimo de similaridade, ordenadas por similaridade decrescente (search_type=blocklisted_or_approvedclassifica primeiro as entradas da lista de bloqueio, depois as da lista de permissões e, em seguida, por similaridade).sourceindica de onde o rosto correspondente foi cadastrado:session, uma sessão de verificação ou uma chamada de API avulsa salva;imported, um rosto enviado diretamente para um perfil de usuário;list_entry, um rosto vinculado a uma das suas listas;retained_template, um template biométrico sem imagem que a aplicação manteve após excluir a sessão de origem.session_id,session_number,statuseapi_servicesãonullem correspondênciasimported,list_entryeretained_template.- Correspondências
retained_templatecontêmvendor_user_id,vendor_dataebiometric_template_id, e trazem semprenullemmatch_image_url,user_detailse em tudo o que se refere à sessão: a sessão que gerou o rosto não existe mais e o template não guarda nenhuma imagem nem dado de identidade.is_blocklistedé semprefalsepara um template retido; um rosto da lista de bloqueio é informado separadamente como uma correspondêncialist_entry. Exclua o template comDELETE /v3/biometric-templates/{biometric_template_id}/. api_serviceé o tipo de API avulsa da sessão correspondente (em maiúsculas, por exemploPASSIVE_LIVENESS) e énullquando o rosto correspondente veio de uma sessão de verificação comum de um fluxo de verificação (workflow).user_detailsvem da verificação de documento da sessão correspondente. Em correspondênciassource: imported, ele é preenchido a partir do perfil do usuário (full_namepreenchido,document_type/document_numbernulos); énullquando não há dados de identidade (por exemplo, em sessões apenas de prova de vida).- Os avisos usam uma estrutura reduzida em comparação com os avisos de fluxo: não há
node_id. O contrato de resposta documentado (FaceSearchResponseSerializer) declara os cinco camposrisk,additional_data,log_type,short_descriptionelong_description; o payload em tempo de execução também trazfeature, que aqui é sempre"LIVENESS". Consulte Avisos da Busca facial. - Correspondências com o mesmo usuário não são excluídas: diferentemente da detecção de duplicados nos fluxos, o endpoint avulso não filtra sessões anteriores com o mesmo
vendor_data, portanto, um usuário legítimo que retorna tem correspondência com as próprias sessões anteriores.
Valores de status
Oface_search.status de nível superior é derivado de warnings[]. O status de cada correspondência reflete o resultado da verificação da sessão correspondente e é independente.
Observação: quando a imagem buscada não contém nenhum rosto detectável, a API retorna HTTP
400 com {"error": "No face detected in the image"} antes de um objeto face_search ser criado; não existe status Declined para esse caso. Créditos insuficientes retornam HTTP 403 antes de qualquer processamento da imagem.
Exemplos
Aprovado: correspondência duplicada, sem lista de bloqueio
Recusado: correspondência na lista de bloqueio
Relacionados
- Avisos da Busca facial: todos os códigos de aviso que a busca pode emitir
- Referência da API de Busca facial: parâmetros da requisição e modos de
search_type - Modelos de dados: Busca facial: schema canônico
- Webhooks: payloads de
status.updatedpara sessões persistidas
Quando
save_api_request=true, os valores de match_image_url são URLs assinadas e de curta duração. Consulte novamente o endpoint de decisão da sessão com o request_id retornado para obter URLs novas. Quando save_api_request=false, eles são caminhos internos de armazenamento e não podem ser baixados diretamente. Armazene do seu lado apenas o ID da sessão correspondente, o status e o similarity_percentage. Não retenha a imagem biométrica subjacente.