Docs

POST /v1/atos with the type, the subject (an opaque client reference and, if any, the transient reference image), the opaque context and the minimum level. The gateway resolves the policy and returns the steps and the journey link.

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

GET /v1/atos with filters by type and state; 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/lote creates many acts of the same type with links and a common deadline, for campaigns and proof of life. POST /v1/mandatos/{id}/revogar. POST /v1/atos/prova-excecao/fonte queries a vital-status source on demand and, if there is an alert, opens the exception proof.

GET /v1/politica returns the effective policy per type: level, steps, deadline, label and whether it is executable today. 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.

Endpoints per client with a rotatable secret, signed delivery and a delivery log; test ping from the dashboard. Events: check.completed, check.approved, check.rejected, check.needs_review, check.failed, check.expired and recibo.emitido.

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

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.

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

dash.hummand.com.br: generate the link, acts, receipts with batch export, mandates, alerts, read-only policy, privacy, API keys, team, webhooks, audit and usage.

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 (73 routes in ten routers) 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.