> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kycert.com.br/llms.txt
> Use this file to discover all available pages before exploring further.

# Verificação Facial

> Face Match, Passive Liveness e os dois fluxos disponíveis via API

## O que é

O kycert oferece dois checks biométricos:

**Face Match** compara o rosto de uma selfie com o de uma segunda imagem — tipicamente a foto de um documento de identidade — e retorna se são a mesma pessoa.

**Passive Liveness** verifica se a selfie enviada é de uma pessoa real, ao vivo, e não de uma foto, tela ou máscara reapresentada à câmera (anti-spoofing) — sem exigir gestos, piscadas ou vídeo do titular.

## Dois fluxos

| Fluxo | Como dispara | Quando usar |
| - | - | - |
| **Automático** | Par selfie + documento de identidade completo via [POST /customers](/api-reference/createCustomer#verificação-facial-automática)/[POST /customers/{id}/documents](/api-reference/uploadCustomerDocument#verificação-facial-automática) | Onboarding padrão — a verificação faz parte do cadastro do cliente, resultado consultado depois via `GET` ou webhook |
| **Avulso** | [POST /verificacoes/facial](/api-reference/verificarFacial) | Validar biometria sem criar cadastro, ou sem depender do par selfie+identidade estar completo no cadastro |

O fluxo automático sempre grava o resultado vinculado ao `customer`. O avulso nunca vincula — `customer_id` é sempre `null`, só serve para reconciliação de billing/suporte.

## Pré-requisito: ativação em duas camadas

Nenhum dos dois fluxos roda sem as duas camadas ativas, e nenhuma delas é acionável via API:

1. **Módulo "Verificação facial"** — ativado pelo master para o tenant.
2. **Configuração do tenant** — habilitada pelo compliance officer no dashboard do tenant.

Com qualquer uma das duas desligada, o par selfie+identidade é apenas armazenado (fluxo automático) ou a chamada retorna `403 module_disabled` (fluxo avulso) — sem nenhuma verificação rodando.

## Como consultar o resultado do fluxo automático

O resultado nunca vem na resposta síncrona de `POST /customers` ou `POST /customers/{id}/documents` — é sempre assíncrono. Duas formas de consultar:

* **`GET /customers/{id}`** — campo `facial_verification` com o resultado da rodada mais recente. Melhor para quem só confere ocasionalmente (polling).
* **Webhook `biometric_check.completed`** — notifica assim que a rodada termina, mesmo secret HMAC dos eventos de bureau. Melhor para quem já automatiza reação a eventos. Ver [Webhooks](/webhooks).

(O fluxo avulso não precisa dessas duas formas — o resultado já volta na própria resposta HTTP.)

## Sandbox

Mesmo padrão do resto da API: chave `sk_test_...` decide sandbox (nunca o conteúdo da imagem), sem cobrança, `livemode: false` na resposta e no payload do webhook.

## Billing

Verificação bem-sucedida consome o mesmo saldo do tenant que bureau runs consomem — não é um sistema de cobrança separado.

## Dados e privacidade

O provedor de verificação processa as imagens enviadas mas **não as armazena** do lado dele — toda chamada é feita com `save_api_request: false`. A persistência do resultado (e, quando aplicável, das imagens de entrada) é 100% na base do kycert.

<Warning>
  A formalização da base legal LGPD Art. 11 para tratamento de dado biométrico e a confirmação da localização de processamento pelo provedor **estão em aberto**, sem prazo definido. Isso não bloqueia o uso em sandbox, mas é uma pendência jurídica que deve ser resolvida antes de qualquer tenant operar verificação facial em produção real. Nenhuma declaração de conformidade LGPD garantida ou auditada pode ser feita até essa pendência ser fechada.
</Warning>


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