Docs

POST /v1/atos with the type, the subject (an opaque client reference and, if any, the reference image, encrypted only while the act is open, up to 30 days), the opaque context and the minimum level. The gateway resolves the policy and returns the steps and the journey link.

With the reference image, live presence comes with match: it is the same person as the reference. Without it, the step is live presence, without match.

Types whose steps do not execute yet respond 501 saying which step is missing; nothing is simulated.

GET /v1/atos with filters by type, state, result, client reference, batch and period, and the step trail of each act (etapas=0 skips it); GET /v1/atos/contagem, the total of the same query; GET /v1/atos/exportar, the same query as CSV, up to 50,000 rows and with no data about the data subject; GET /v1/atos/{id} with the steps in the server's order, the scope, the chaining, the context as a hash only and the minimized verdict; POST /v1/atos/{id}/cancelar. The person advances through POST /v1/atos/{id}/etapas/{nome}, by the act token.

POST /v1/atos/{id}/evidencia opens what the act keeps encrypted, and requires a person at supervisor level, a declared reason, and leaves a record. Absence is declared in three distinct states: open, erased and never existed, because merging the last two would erase the difference between an erasure that happened and a field never filled in.

GET /v1/atos/{id}/evidencia/acessos returns who opened it, when and with what reason, with openings made by Hummand among them and the hash link of each one. It is the route the client dashboard loads before any opening. Each line carries the previous link and the request id, and can be checked on its own.

GET /v1/atos/{id}/acessos and GET /v1/acessos return the signed humanproof-acesso/1 receipts of those openings, in a chain of their own per client.

POST /v1/atos/lote creates many acts of the same type with links and a common deadline, for campaigns and proof of life; a larger campaign is created in parts of up to 500, which carry on as one through the lote_id. GET /v1/atos/lotes lists the campaigns, with name, owner and progress; GET /v1/atos/lotes/{id}/relatorio accounts for each act with the receipt that proves it, and GET /v1/atos/lotes/{id}/recibos returns the continuous stretch of the chain; GET /v1/atos/lotes/{id}/pendentes returns who is missing, with a reissued link. POST /v1/atos/{id}/referencia attaches the enrolment photo after creation. POST /v1/atos/prova-excecao/fonte queries a vital-status source on demand and, if there is an alert, opens the exception proof.

Mandate: GET /v1/mandatos lists those granted, with who received the authority, status and validity; GET /v1/mandatos/{id} returns the state and the whole scope, for the executor to compare against the action Hummand does not know; POST /v1/mandatos/{id}/revogar takes one down; POST /v1/mandatos/revogar-lote takes down every mandate of one holder or one client, with one receipt per mandate taken down, because what an auditor checks is each authority that fell.

GET /v1/politica returns the effective policy per type: level, steps, deadline, label and whether it is executable today. PUT /v1/politica, by the Administrator, hardens the global one per type, and every edit is a new version, listed in GET /v1/politica/versoes; GET /v1/politica/etapas gives the real state of each step. GET /v1/alerts computes the three situations on read, with a filter by type.

The check routes remain as an alias for one version. POST /v1/document validates civil identity (mock or real, depending on accreditation). Standalone POST /v1/match and POST /v1/cpf respond 501 by design: outside an act, there is no proof.

GET /v1/atos/{id}/recibo returns the signed receipt, or 202 while pending. GET /v1/recibos returns the batch in chain order, filtered by issue date: it is what you export to verify outside. GET /v1/verification-links/{token}/recibo is the proof for whoever did the journey.

The public key is at /.well-known/humanproof/keys.json, as a JWKS.

GET /v1/recibos/ponto returns a signed object, with the same key as the receipts, stating how many receipts existed and what the last hash was. It closes the only case the chaining alone does not cover: the cut at the end.

Whoever audits keeps the checkpoint outside Hummand and compares later. There is no table of ours listing issued checkpoints: the only copy that counts is the auditor’s.

Endpoints per client with a rotatable secret, signed delivery and a delivery log; test ping from the dashboard. Eleven signable events, in two vocabularies: the six legacy check ones (completed, approved, rejected, needs_review, failed, expired), the three act ones (ato.concluido, ato.em_revisao, ato.expirado), recibo.emitido and mandato.revogado.

Both vocabularies coexist because the legacy payload carries no type, level or result, and without those a level-0 delegated act would arrive indistinguishable from a recurring presence. mandato.revogado exists so that whoever caches authority stops accepting it without asking Hummand on every action.

The payload carries no personal data by construction: ids, type, state, result and hashes; never a CPF, never content.

On the sixth failure the event is marked exhausted, and is not lost: GET /v1/webhooks/esgotados lists the exhausted ones, and POST /v1/webhooks/esgotados/{id}/reentregar puts one back in the queue, with the same event_id, so the receiver can deduplicate.

The same transitions become dashboard notifications, with preferences per channel and per type.

verificar.hummand.com.br/s/{token} renders the steps in the server's order: context transparency, general and biometric consent, live presence on demand, result and proof. A step the gateway does not execute appears as not available yet, never as success.

The enrolment photo can be attached to each act after creation, in the batch too, from the dashboard or through POST /v1/atos/{id}/referencia; with it, presence comes with match. Without it, the step is live presence, without match.

Sandbox with a simulated result to test the integration without consuming presence or entering the chain.

dash.hummand.com.br: create acts and batch campaigns, acts with search and CSV export, the act dossier, search, my queue, receipts with batch export, mandates, alerts, the live screen, editable orchestrations, reverification cycles, units, privacy with retention, API keys, team with access levels and access review, sessions, password, passkey and SSO, webhooks, audit, analytics by period, usage and support.

Routes the dashboard uses and the API exposes with the same contract: GET /v1/ao-vivo, GET /v1/analytics with a free period and comparison, GET /v1/audit paginated and filterable, GET /v1/auth/sessions, POST /v1/auth/sessions/encerrar-outras and POST /v1/auth/senha.

Since 0.23.0: GET /v1/atos/{id}/dossie, GET /v1/busca, GET /v1/atos/fila, POST /v1/atos/{id}/demonstracao (test acts only), /v1/auth/passkeys and POST /v1/auth/passkey, /v1/auth/sso/{provedor}/iniciar and /v1/sso, /v1/lista-ip, /v1/unidades, /v1/retencao and /v1/retencao/preservacoes, /v1/acessos/config and /v1/acessos/revisao, /v1/ciclos and /v1/suporte/chamados.

The OpenAPI contract is exported from the application and versioned; the TypeScript client is generated from it and its version follows the gateway's. CI fails if contract and client diverge; nothing is written by hand. Private distribution until a recorded decision.

The interactive API reference stays behind the edge access until the public documentation. Ask for access through the contact; the conversation is technical, straight with the people who build it.