API REST · GET JSON CNF-API-Authorization Webhook

Consulte informações de óbitos diretamente pelo seu sistema

Estamos transformando uma das maiores bases de informações de óbitos do país em uma solução pronta para integração .

E não estamos falando apenas de saber se existe ou não um óbito.

CPF
Nome
Data
Cidade
UF

A proposta é permitir que empresas consultem essas e outras informações diretamente pelos seus sistemas, com rapidez e escala.

Aplicações:

Higienização de bases · Validação cadastral · Prevenção a fraudes · Jurídico · Cobrança · Seguros e diversas outras operações.

GET
Método suportado
1
Registro por consulta
30 dias
Prazo médio webhook
429
Rate limit / quota
PRODUÇÃO REST JSON 1 REGISTRO

1. Visão geral

A API expõe um endpoint de consulta de falecidos via HTTP GET. Os parâmetros são enviados na query string. A resposta segue um envelope JSON consistente com os campos success, data, meta e error.

🔎 Resultado único: A API retorna apenas 1 registro — aquele com a maior pontuação de similaridade em relação aos critérios informados. Não há paginação de múltiplos resultados; quando um registro é encontrado, ele é o mais relevante disponível.
GET https://api.falecidosdobrasil.com.br/v1/obitos
01

2. Autenticação

A API utiliza o header proprietário CNF-API-Authorization para autenticação. A chave de API deve ser enviada diretamente nesse header, sem prefixos adicionais.

ÚNICO MÉTODO Header proprietário

CNF-API-Authorization

CNF-API-Authorization: SUA_API_KEY

Envie a chave diretamente, sem o prefixo Bearer ou qualquer outro.

⚠️ Não envie a API Key na URL. Não use ?api_key=.... Além de não ser a forma implementada no código, isso pode expor a credencial em histórico, logs e ferramentas de observabilidade.

3. Fluxo da requisição

1

Método

A API aceita GET. Qualquer outro método retorna HTTP 405.

2

Autenticação

A chave é localizada nos headers e validada contra o cliente e o plano.

3

Autorização e limites

O cliente precisa estar ativo, o plano precisa estar ativo e a feature consulta_imediata, quando definida, precisa estar habilitada. Depois são conferidos limites por minuto, dia, mês e total.

4

Normalização

O nome é higienizado, convertido para maiúsculo e tem tags/caracteres inválidos removidos. O CPF é normalizado para somente dígitos. Datas precisam estar em YYYY-MM-DD.

5

Consulta e similaridade

Os filtros são aplicados sobre o nome, CPF, estado, cidade e data. A API ordena por similaridade e retorna apenas o registro mais relevante (maior pontuação).

6

Resposta

A saída é um envelope JSON. Quando não há resultado imediato e webhooks estão habilitados, a busca é registrada para tratamento manual (veja a seção Webhook).

4. Parâmetros

Todos são query parameters porque o endpoint é GET.

QUERY STRING
Campo
Tipo
Descrição
Obrigatório
nomefal
string
Nome da pessoa. É higienizado e convertido para maiúsculo. A consulta usa LIKE e, para nomes com 4+ caracteres, também pode usar SOUNDEX.
Não
cpf
string
CPF ou identificador numérico aceito pelo código. A entrada é normalizada removendo tudo que não é dígito. A validação implementada aceita comprimento 11 ou 14.
Não
data_exata
date
Data exata do falecimento no formato YYYY-MM-DD. Quando informada, substitui o filtro por intervalo.
Não
data_ini
date
Início do período, formato YYYY-MM-DD.
Não
data_fim
date
Fim do período, formato YYYY-MM-DD.
Não
estadofal
integer
ID do estado (código numérico de 1 a 27). O código procura também a sigla correspondente e permite compatibilizar registros cujo UF esteja armazenado como texto.
Não
cidadefal
integer
ID da cidade (código numérico específico). A consulta considera tanto cidade armazenada como código quanto cidade resolvida por nome.
Não
Código UF Nome do Estado
📅 Regra das datas: se data_exata for enviada, a consulta usa somente essa data. Caso contrário, data_ini e/ou data_fim podem formar um intervalo. A API rejeita o período quando a data inicial é maior que a final.

5. Estrutura da resposta JSON

O envelope é padronizado. O campo data carrega o registro de maior similaridade; meta traz os filtros aplicados; error fica preenchido nas respostas de erro.

Resposta de sucesso
{
  "success": true,
  "data": {
    "indice": 0,
    "registro": {
      "U_ID": 1,
      "ID": 44940177,
      "Cpf": 0,
      "NomeFalecido": "LUIZ ALBERTO DA SILVA",
      "DataNascimento": "-",
      "NomeMae": "LUIZA CERBIA DA SILVA",
      "NomePai": "-",
      "DataFalecimento": "2018-12-28",
      "Cartorio_OrigemFonte": "202",
      "Cartorio_Codigo": 0,
      "Livro": "-",
      "Folha": "-",
      "Termo": "-",
      "DataLavramento": "-",
      "Cidade": "Porto Ferreira",
      "UF": "SP",
      "cidade_id_cod": null,
      "nome_cidade_cod": null,
      "estado_id_cod": null,
      "uf_cod": null,
      "cidade_id_nome": null,
      "nome_cidade_nome": null,
      "estado_id_nome": null,
      "uf_nome": null,
      "cidade_resolvida": "Porto Ferreira",
      "uf_resolvida": "SP"
    },
    "similaridade": 0.775,
    "percentual": 77.5
  },
  "meta": {
    "page": 1,
    "limit": 10,
    "count": 3,
    "has_more": false,
    "next_page": null,
    "response_time_ms": 1.07,
    "filters": {
      "nomefal": "LUIZ ALBERTO DA SILVA",
      "cpf": null,
      "data_exata": null,
      "data_ini": null,
      "data_fim": null,
      "estadofal": null,
      "cidadefal": null
    }
  },
  "error": null
}
Resposta de erro
{
  "success": false,
  "data": null,
  "meta": [],
  "error": {
    "code": "INVALID_API_KEY",
    "message": "API Key inválida."
  }
}
💡 Similaridade: O campo similaridade representa a pontuação de compatibilidade entre a consulta e o registro retornado. Quanto mais próximo de 1.0, maior a confiança na correspondência.

6. Rate limit e headers

A API contabiliza requisições por minuto, dia, mês e total, conforme o plano do cliente. Quando os limites estão definidos, a resposta de sucesso também pode trazer headers de consumo.

X-RateLimit-Limit-Minute
limite de requisições por minuto
X-RateLimit-Remaining-Minute
saldo de requisições do minuto
X-RateLimit-Limit-Day
limite diário
X-RateLimit-Remaining-Day
saldo diário
⚠️ Controle recomendado no cliente: trate HTTP 429 com backoff e monitore os headers retornados. O limite exato depende do plano do cliente e não está fixado no código do endpoint.

7. Códigos HTTP e erros

HTTP Código Quando acontece
401 AUTH_REQUIRED
INVALID_API_KEY
Credencial ausente ou inválida.
403 CLIENT_BLOCKED
PLAN_INACTIVE
FEATURE_NOT_ALLOWED
Cliente, plano ou funcionalidade não autorizados.
405 METHOD_NOT_ALLOWED Método diferente de GET.
422 VALIDATION_ERROR Parâmetros inválidos, principalmente CPF ou datas.
429 RATE_LIMIT_EXCEEDED
DAILY_QUOTA_EXCEEDED
MONTHLY_QUOTA_EXCEEDED
QUOTA_EXCEEDED
Limites de consumo atingidos.
500 DATABASE_CONNECTION_ERROR
PROCEDURE_ERROR
STATE_LOOKUP_ERROR
QUERY_ERROR
Falha interna de infraestrutura/processamento.

8. Exemplos de integração


const API_URL = "https://api.falecidosdobrasil.com.br/v1/obitos";
const API_KEY = "SUA_API_KEY";

const params = new URLSearchParams({
  nomefal: "NOME DA PESSOA",
  estadofal: "25",   // Código do estado (ex: 25 = São Paulo)
  cidadefal: "3550308" // Código da cidade
});

const response = await fetch(`${API_URL}?${params}`, {
  method: "GET",
  headers: {
    "CNF-API-Authorization": API_KEY,
    "Accept": "application/json"
  }
});

const result = await response.json();

if (!response.ok) {
  console.error("Erro:", result.error);
  throw new Error(result.error?.message || "Falha na API");
}

// result.data contém o registro de maior similaridade
console.log(result.data);

WEBHOOK BUSCA MANUAL 30 DIAS

9. Webhook e busca manual

Quando a consulta não encontra nenhum registro na base imediata, o sistema automaticamente registra a solicitação para uma busca manual em diversos cartórios e outras fontes disponíveis. Se o registro for localizado dentro do prazo, um webhook é disparado para o endpoint cadastrado pelo cliente.

1. Consulta sem resultado imediato

A API retorna success: true com data: null e o campo meta.busca_manual_registrada: true, indicando que a solicitação foi enfileirada para investigação.

2. Pesquisa manual em cartórios

Nossa equipe realiza buscas em cartórios de registro civil, bases de dados públicos e outras fontes disponíveis. O prazo médio para conclusão é de 30 dias.

3. Registro localizado

Se o registro do falecido for encontrado dentro do prazo, um POST é enviado para o endpoint de webhook cadastrado, contendo os dados completos do registro.

4. Notificação no seu endpoint

O payload do webhook inclui o ID da consulta original, os dados do registro encontrado e o score de similaridade. Sua aplicação pode então processar a notificação automaticamente.

⏱️ Prazo médio
Aproximadamente 30 dias corridos
🔔 Método do webhook
POST com payload JSON

Exemplo de payload do webhook

{
  "event": "registro_localizado",
  "consulta_id": "a3f8c2e1-9b4d-4e7f-8a1c-5d6e7f8a9b0c",
  "data": {
    "NomeFalecido": "MARIA DA SILVA",
    "Cpf": "12345678901",
    "DataFalecimento": "2024-08-10",
    "DataNascimento": "1955-01-14",
    "NomeMae": "JOANA DA SILVA",
    "NomePai": "JOAO DA SILVA",
    "cidade_resolvida": "SAO PAULO",
    "uf_resolvida": "SP",
    "similaridade": 0.987
  },
  "timestamp": "2024-09-15T14:30:00Z"
}
📌 Configuração: O endpoint de webhook deve ser cadastrado previamente no painel do cliente. Recomenda-se que o endpoint responda com HTTP 200 para confirmar o recebimento. Caso o endpoint não responda, o sistema pode tentar reenvios com backoff exponencial.
SIMULADOR LOCAL

10. Teste da API sem chamar o servidor

Este console executa uma simulação 100% local em JavaScript. Nenhuma API Key é enviada para a internet e nenhuma requisição real é feita. Use os códigos de estado e cidade abaixo para testar.

Modo offline
GET•JSON•Sem rede
Resposta simulada Aguardando
HTTP
—
Tempo
—
Registros
—

                

11. Checklist para o desenvolvedor