Skip to main content
O caminho feliz é minoria. A maior parte dos chamados de integração vem do titular que abandonou, voltou dois dias depois e encontrou uma tela quebrada.

Confira o exemplo

Os arquivos desta POC, com o destino de cada um.

As três situações

A primeira linha é a que a idempotência resolve sozinha. Repetir a criação com o mesmo ref_id e o mesmo corpo devolve 200 com a verificação que já existe, em vez de criar uma segunda.

A rota

app/api/verifications/route.ts
O ref_id é único por conta. Reaproveitá-lo depois da expiração com um corpo diferente responde 409 E_REF_ID_CONFLICT — por isso o sufixo de tempo quando a jornada precisa recomeçar.

O que o status diz

A criação repetida devolve a verificação com o status de agora, não o de quando foi criada: Use isso para a sua tela: quem está em started merece “continue de onde parou”, não “comece agora”.

Não fique perguntando

O expires_at que você gravou já responde se a jornada vale. Consultar a Legitimuz num intervalo para descobrir isso gasta o teto da sua chave e não traz nada que o webhook não traga.

Antes de rodar

.env
Use uma integração sandbox. Nenhum dos três valores vai para o browser ou para o app.

O que esta POC não faz

POC é código para entender o fluxo, não para copiar em produção. Em todas elas, authenticate() é um stub, db é um objeto de mentira e não há migration, observabilidade nem retentativa própria.
  • Sem limite de quantas vezes o mesmo cadastro pode recomeçar.
  • Sem aviso ao titular de quanto tempo resta.
  • Sem tratamento de CPF trocado entre uma tentativa e outra.

Próximo passo

Status da verificação

Os cinco status e o que cada um significa.

Criar verificação

A idempotência por ref_id, em detalhe.