Docs

POST /v1/atos com o tipo, o sujeito (uma referência opaca do cliente e, se houver, a imagem de referência, transiente), o contexto opaco e o nível mínimo. O gateway resolve a política e devolve as etapas e o link da jornada.

Tipos cujas etapas ainda não executam respondem 501 dizendo qual etapa falta; nada é simulado.

GET /v1/atos com filtros por tipo e estado; GET /v1/atos/{id} com as etapas na ordem do servidor, o escopo, o encadeamento, o contexto só como hash e o veredito minimizado; POST /v1/atos/{id}/cancelar. A pessoa avança por POST /v1/atos/{id}/etapas/{nome}, pelo token do ato.

POST /v1/atos/lote cria vários atos do mesmo tipo com links e prazo comum, para campanhas e prova de vida. POST /v1/mandatos/{id}/revogar. POST /v1/atos/prova-excecao/fonte consulta uma fonte de estado vital a pedido e, se houver alerta, abre a prova de exceção.

GET /v1/politica devolve a política efetiva por tipo: nível, etapas, prazo, rótulo e se é executável hoje. GET /v1/alerts computa as três situações na leitura, com filtro por tipo.

As rotas de checks seguem como alias por uma versão. POST /v1/document valida identidade civil (mock ou real, conforme o credenciamento). POST /v1/match e POST /v1/cpf avulsos respondem 501 por desenho: fora de um ato, não há prova.

GET /v1/atos/{id}/recibo devolve o recibo assinado, ou 202 enquanto pendente. GET /v1/recibos devolve o lote na ordem da cadeia, com filtro por data de emissão: é o que se exporta para verificar fora. GET /v1/verification-links/{token}/recibo é o comprovante de quem fez a jornada.

A chave pública está em /.well-known/humanproof/keys.json, como JWKS.

Endpoints por cliente com segredo rotacionável, entrega assinada e log de entregas; ping de teste pelo painel. Eventos: check.completed, check.approved, check.rejected, check.needs_review, check.failed, check.expired e recibo.emitido.

O payload é sem dado pessoal por construção: ids, tipo, estado, resultado e hashes; nunca CPF, nunca conteúdo.

As mesmas transições viram notificações no painel, com preferências por canal e por tipo.

verificar.hummand.com.br/s/{token} renderiza as etapas na ordem do servidor: transparência do contexto, consentimentos geral e biométrico, presença viva sob demanda, resultado e comprovante. Uma etapa que o gateway não executa aparece como ainda não disponível, nunca como sucesso.

Sandbox com resultado simulado para testar a integração sem consumir presença nem entrar na cadeia.

dash.hummand.com.br: gerar o link, atos, recibos com exportação do lote, mandatos, alertas, política em leitura, privacidade, chaves de API, equipe, webhooks, auditoria e uso.

O contrato OpenAPI é exportado da aplicação e versionado; o cliente TypeScript é gerado dele e a versão acompanha a do gateway. O CI falha se contrato e cliente divergirem; nada é escrito à mão. Distribuição privada até decisão registrada.

A referência interativa da API (73 rotas em dez routers) fica atrás do acesso da borda até a documentação pública. Peça o acesso pelo contato; a conversa é técnica, direto com quem constrói.