Base URL
Todas as requisições partem desta URL, sempre por HTTPS.Autenticação
Envie sua chave de API no cabeçalhoAuthorization.
Objetos
Toda resposta traz um campoobject que diz o que você recebeu: validation, api_key ou list. Os identificadores levam um prefixo do tipo, seguido de um ULID: val_ para validações, key_ para chaves.
Datas são strings ISO-8601 em UTC.
Idempotência
Os três endpoints de criação de validação aceitam o cabeçalhoIdempotency-Key. Reenviar a mesma chave devolve a resposta original em vez de criar e cobrar outra validação.
Idempotent-Replayed: true.
Use uma chave nova por operação de negócio, e a mesma chave em todas as retentativas dessa operação. Reaproveitar a chave com um corpo diferente responde 400 com idempotency_key_reuse.
POST /api-keys não aceita Idempotency-Key. Cada chamada emite um segredo novo, por definição.Códigos de resposta
Nas criações de validação,
200 e 201 marcam modos de execução diferentes. Vínculo entre CPF e telefone e troca de chip resolvem dentro da requisição e respondem 200, com o resultado no corpo. Prova de vida + documento responde 201: cria uma validação pending, com validation_url para o titular, cujo resultado você busca depois em GET /validations/{id}.
A diferença entre 400 e 422 é deliberada: 400 é problema de contrato (campo faltando, tipo errado), 422 é problema de conteúdo (um CPF que não passa no dígito verificador, por exemplo).
Todo erro responde no mesmo formato, com um code estável e um doc_url que aponta para a explicação. A lista completa está em Erros.
Por onde começar
Vínculo entre CPF e telefone
Validação síncrona: a resposta já traz o resultado.
Prova de vida + documento
Validação hospedada: você redireciona o titular e consulta depois.