Autenticação
Chamadas REST usam Bearer token no header. A chave secreta define o ambiente:sk_test roda em sandbox, sk_live em produção. Nunca exponha a secret no front: ela é só server-side.
curl · Criar a sessão · no terminal
401 invalid_api_key: crie outra no painel e troque na integração.
Revogar uma chave, por você ou pela UNIFOKAL, corta também o que ela emitiu e ainda não começou: o link de verificação ainda não usado deixa de abrir e a sessão que o titular ainda não enviou deixa de valer. A verificação já enviada segue, é decidida e chega ao seu webhook. Para trocar a chave sem cancelar nada, use Rotacionar com prazo no painel: a chave antiga continua valendo até o prazo (até 7 dias) e o que ela já criou segue até o próprio vencimento.
Todo erro tem a mesma forma: { "error": "<código>", "message": "<texto>" }. Trate pelo error, que é contrato estável dentro de /v1. O message é para humano e pode mudar sem aviso. A lista completa dos que você encontra no primeiro dia está logo abaixo.
curl · Os erros que você vai encontrar no primeiro dia · no terminal
Segurança do fluxo
O front recebe do seu backend apenas osessionId (vs_), escopado a UMA única sessão (uso curto, com TTL). Ele é a credencial do widget: nenhum segredo vai ao navegador. Não é uma chave global: só habilita a captura daquela verificação, então expor por engano não compromete outras sessões nem a sua conta. A sk_ (secret), usada no backend para criar a sessão, é a única credencial sensível e nunca sai do servidor. A captura e o processamento acontecem no UNIFOKAL; o resultado oficial só trafega no webhook assinado para o seu backend.
Encontrou uma vulnerabilidade? A política de divulgação responsável diz como relatar, o escopo e o que esperar, e o arquivo /.well-known/security.txt traz os mesmos canais em formato legível por máquina. Os documentos de segurança, privacidade e contrato ficam reunidos na central de confiança.