Lista de bloqueio
Marque um titular e novas verificações dele voltamblocked (evento verification.blocked) e não são cobradas. O bloqueio pode valer para a conta inteira, em todos os flows, ou só para um flow: a lista da conta vale em todos, e a do flow acrescenta. O valor marcado é guardado cifrado e nunca volta em texto puro.
A exceção é o bloqueio por sócio do quadro societário, no flow com cnpj_partners: ele só aparece depois que a leitura do documento e a consulta do quadro foram entregues, e você recebe esse resultado. Por isso a verificação termina em blocked com reason igual a partner_blocklisted e cobra os módulos entregues, com a parcela por sócio, e não o resto.
Além de CPF, CNPJ e documento estrangeiro, a lista aceita o reference_id, o identificador do titular no seu sistema, que você envia ao criar a sessão. É a chave que existe antes de haver documento: serve para barrar quem abandonou a verificação no meio ou um titular que você já decidiu não atender. A partir dele, a próxima verificação daquele reference_id termina em blocked, sem cobrança, e o webhook verification.blocked traz reason igual a reference_blocklisted. Ao titular, a tela informa apenas que a empresa registrou uma restrição. Use sempre o mesmo reference_id para o mesmo titular, de preferência com letras, números e os sinais . _ : @ -. A comparação não distingue maiúsculas de minúsculas: User_42 e user_42 são o mesmo titular, então quem você bloqueou numa grafia fica bloqueado em todas. O bloqueio por referência vale só na sua organização e nunca é compartilhado com empresas vinculadas.
No painel, você bloqueia a partir da linha da verificação, que é onde acabou de ver o caso, e desbloqueia o titular em Sessões. Os interruptores de bloqueio automático são configuração do flow, junto do resto da política.
Cada bloqueio dura o prazo do seu tipo de identificador. CPF, CNPJ e reference_id valem enquanto você mantiver o bloqueio: CPF e CNPJ não passam a designar outra pessoa, e o reference_id é do seu sistema. O documento estrangeiro sai da lista 10 anos depois do bloqueio, e o prazo recomeça se você bloquear de novo, porque um documento de viagem não segue válido por mais tempo do que isso. Quando um bloqueio passa 24 meses sem barrar ninguém, o painel mostra ao lado dele o selo Sem uso há mais de 24 meses, para você revisar se ele ainda faz sentido. O selo não remove nada: a decisão continua sua.
Sandbox
O sandbox roda o pipeline completo, grátis e com teto mensal (livemode:false). CPFs determinísticos disparam cada resultado para você testar o webhook sem capturar nada:
document do POST /v1/verification-sessions/self/submit, autenticado pelo id da sessão no cabeçalho Authorization (o caminho leva self, nunca o id). O widget submete sem esse campo, então uma sessão de sandbox concluída pelo widget sempre termina aprovada: para ver o -01, o -02, o -04 e o -05, chame o submit pela API.
Os sufixos -04 e -05 testam o webhook de atualização sem esperar um caso real. A verificação termina em review agora e você recebe o primeiro verification.completed. Cerca de 60 segundos depois (até 75), ela é decidida de novo e chega um segundo verification.completed, com um id de evento novo, terminado em _r<número>, e o status final: approved no -04, denied no -05. Se alguém decidir a verificação pelo painel antes disso, vale a decisão da pessoa e o segundo evento não sai. Nada disso é cobrado.
O sufixo -06, no campo document do submit, testa o modo expresso sem esperar uma análise lenta de verdade. Num flow com cpf_ocr, só esse módulo espera cerca de 60 segundos antes de analisar, e depois aprova. No modo expresso chegam dois verification.completed: o primeiro em review, sem esperar o cpf_ocr, e o segundo com o status final e o id de evento terminado em _r<número>. No modo completo chega um só, cerca de 60 segundos depois do envio. Nada disso é cobrado.
Sandbox e produção: o que muda
O pipeline é o mesmo e o formato da resposta é o mesmo. O que muda está nesta tabela, e vale a pena ler antes do go-live, não depois: metade destes itens só aparece quando você troca a chave.
Não existe rota
sk_ que leia o resultado de uma verificação. Tentar GET /v1/verifications/{id} com a chave secreta devolve 403 credential_type_not_allowed: aquela rota é do painel. O resultado chega ao seu servidor pelo webhook, e GET /v1/webhook-events lista o que ainda não foi entregue.