DataJud do CNJ: O Que É, Como Usar (e Quando Não Usar) em 2026

O DataJud é a base nacional de dados processuais do CNJ — gratuita, pública, RESTful. Pra quem está construindo aplicações jurídicas, é o primeiro recurso a considerar antes de partir pra scraping ou licenças comerciais. Mas o DataJud também tem limitações que não são óbvias na documentação oficial.

Este post cobre o DataJud em profundidade técnica: o que ele entrega de fato, como consultá-lo via REST API, exemplos com cURL e Python, e — talvez mais útil — quando não usá-lo.

O que é o DataJud

O DataJud (Base Nacional de Dados do Poder Judiciário) é o repositório oficial de dados processuais brasileiros mantido pelo CNJ. Foi institucionalizado pela Resolução CNJ 331/2020, que estabelece a obrigatoriedade de todos os tribunais enviarem seus dados processuais ao CNJ via Modelo Nacional de Interoperabilidade (MNI).

Em termos práticos:

• É uma API REST pública acessível sem cadastro
• Os dados são indexados num cluster Elasticsearch mantido pelo CNJ
• A cobertura abrange trinta e tantos tribunais estaduais, federais, do trabalho, eleitorais e militares
• Os dados são metadados processuais: classe, assunto, partes, movimentações — não inclui peças
• Atualização é eventual, com lag oficial de 30 dias (na prática, varia)

A motivação política do DataJud é transparência: tornar a justiça brasileira auditável publicamente, permitir pesquisa empírica, fornecer base pra dashboards públicos de produtividade. A motivação técnica é unificar o que historicamente eram 90+ silos de dados (cada tribunal com seu sistema, layout, schema).

Arquitetura técnica

O backend do DataJud é Elasticsearch — o mesmo engine usado em Wikipedia search, GitHub code search e muitas plataformas de busca corporativa. Isso tem três implicações práticas pra quem consome a API:

1. Sintaxe de query é Elasticsearch DSL, não REST tradicional.

Você não escreve GET /processos?cpf=123. Escreve um JSON Elasticsearch:

{
  "query": {
    "bool": {
      "must": [
        { "match": { "classe.codigo": 7619 } },
        { "range": { "dataAjuizamento": { "gte": "2024-01-01" } } }
      ]
    }
  },
  "size": 100
}

Vantagem: query muito expressiva, suporta agregações estatísticas nativamente (perfeito pra dashboards). Desvantagem: curva de aprendizado pra quem nunca usou Elasticsearch.

2. Endpoints são por tribunal, não unificados.

Cada tribunal tem seu próprio índice no cluster:

• TJSP: https://api-publica.datajud.cnj.jus.br/api_publica_tjsp/_search
• TJRJ: https://api-publica.datajud.cnj.jus.br/api_publica_tjrj/_search
• TJMG: https://api-publica.datajud.cnj.jus.br/api_publica_tjmg/_search
• TRF1: https://api-publica.datajud.cnj.jus.br/api_publica_trf1/_search
• E assim por diante pra cada tribunal

Pra buscar em múltiplos tribunais, é necessário chamar cada endpoint separadamente OU usar a sintaxe Elasticsearch multi-índice (_search?index=*tjsp,*tjrj,*tjmg). A primeira opção é mais comum.

3. Resposta é estrutura Elasticsearch, com hits.hits[] aninhado.

Você precisa parsear response['hits']['hits'] pra obter os documentos reais. Cada documento tem o esquema definido pelo CNJ (campos numeroProcesso, classe, assuntos, movimentos, etc.).

Como começar — primeiro request

O exemplo mínimo que funciona:

curl -X POST 'https://api-publica.datajud.cnj.jus.br/api_publica_tjsp/_search' \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "match": {
        "numeroProcesso": "00012345-67.2024.8.26.0100"
      }
    }
  }'

A resposta vem em estrutura padrão Elasticsearch:

{
  "took": 23,
  "timed_out": false,
  "hits": {
    "total": { "value": 1, "relation": "eq" },
    "hits": [
      {
        "_source": {
          "numeroProcesso": "0001234567.2024.8.26.0100",
          "classe": { "codigo": 7619, "nome": "Procedimento Comum Cível" },
          "assuntos": [{ "codigo": 1127, "nome": "Indenização por Dano Moral" }],
          "dataAjuizamento": "2024-03-15T08:32:00.000Z",
          "movimentos": [
            { "codigo": 26, "nome": "Distribuição", "dataHora": "2024-03-15T08:32:00.000Z" },
            { "codigo": 60, "nome": "Juntada de Petição", "dataHora": "2024-03-22T14:10:00.000Z" }
          ]
        }
      }
    ]
  }
}

Os campos seguem o Modelo Nacional de Interoperabilidade — schema unificado. A vantagem é que o mesmo parser funciona pra todos os tribunais.

Exemplo Python (uso real)

import requests
from typing import List, Dict

DATAJUD_BASE = "https://api-publica.datajud.cnj.jus.br"

def buscar_por_cnj(numero_cnj: str, tribunal: str) -> List[Dict]:
    """
    Busca um número CNJ específico no índice do tribunal.

    `numero_cnj` deve estar no formato 'NNNNNNN-DD.AAAA.J.TR.OOOO'
    `tribunal` em minúsculas, e.g., 'tjsp', 'tjrj', 'trf1'
    """
    url = f"{DATAJUD_BASE}/api_publica_{tribunal}/_search"
    payload = {
        "query": {"match": {"numeroProcesso": numero_cnj.replace("-", "").replace(".", "")}}
    }
    response = requests.post(url, json=payload, timeout=10)
    response.raise_for_status()
    hits = response.json()["hits"]["hits"]
    return [h["_source"] for h in hits]

def buscar_por_classe(classe_codigo: int, tribunal: str, limite: int = 100) -> List[Dict]:
    """
    Lista processos de uma classe específica num tribunal.
    Útil pra estatísticas (e.g., quantos foram distribuídos no mês).
    """
    url = f"{DATAJUD_BASE}/api_publica_{tribunal}/_search"
    payload = {
        "query": {"match": {"classe.codigo": classe_codigo}},
        "size": limite,
        "sort": [{"dataAjuizamento": {"order": "desc"}}]
    }
    response = requests.post(url, json=payload, timeout=15)
    response.raise_for_status()
    return [h["_source"] for h in response.json()["hits"]["hits"]]

# Exemplos
processos = buscar_por_cnj("0001234-56.2024.8.26.0100", "tjsp")
print(f"Encontrados {len(processos)} processos")

ultimas_acoes_indenizacao = buscar_por_classe(7619, "tjsp", limite=50)
print(f"Últimas 50 ações cíveis distribuídas")

Rate limit observado: a API responde 429 quando volume passa de ~30 req/min. Pra loops automatizados, intercale time.sleep(2) ou implemente backoff exponencial. Volumes industriais (milhões de consultas) devem usar a base de dump em formato Parquet, atualizada semanalmente em www.cnj.jus.br/dadosabertos.

O que o DataJud NÃO entrega

Esta é a parte que a documentação oficial subestima.

Não tem busca por CPF ou CNPJ

A API só aceita filtros por: numeroProcesso, classe, assunto, dataAjuizamento, dataAtualizacao, orgaoJulgador, grau. Não há filtro por CPF ou CNPJ de parte. Isso é deliberado — o CNJ argumenta que busca por documento permitiria perfilamento massivo de pessoas, conflitando com a LGPD.

Implicação prática: pra qualquer aplicação que precise “dado um CPF, liste todos os processos da pessoa”, o DataJud não serve. É necessário consulta no portal de cada tribunal — onde a busca por documento existe (ESAJ, PJE) mas é protegida por CAPTCHA precisamente pra evitar scraping massivo.

Caminhos práticos pra resolver isso:

1. Scraping autorizado (Vigilant e similares) — resolve o CAPTCHA, faz a chamada pro portal do tribunal, retorna o resultado em REST estruturado
2. Acesso via API privada dos tribunais (alguns oferecem token pra advogados constituídos) — não escala
3. Construção de índice próprio a partir de scraping massivo — custoso, mas algumas startups jurídicas fizeram

Latência real é maior que documentada

O CNJ documenta lag de 30 dias entre o evento processual e a indexação. Na prática, varia muito por tribunal:

Tribunal	Lag observado
TJDFT	7-15 dias
TJSP	15-30 dias
TJRJ	15-30 dias
TJMG	30-60 dias
TJBA	60-90 dias
TJAC	60-120 dias
Alguns TREs	120+ dias

Pra casos de uso operacionais (monitoramento de prazos, alertas de novas ações), DataJud não atende. Vale só pra análises retrospectivas — estatísticas, dashboards, pesquisa empírica.

Não tem peças, só metadados

Você tem o número CNJ, classe, assunto, lista de movimentações com tipo e data. Não tem o conteúdo das petições, decisões, despachos. Pra acessar isso, é necessário ir ao portal do tribunal com autenticação adequada (advogado constituído via certificado digital).

Cobertura tem gaps

A Resolução 331/2020 obriga, mas implementação varia. Em 2026, ~28 dos 91 órgãos do Judiciário enviam dados completos e atualizados. O resto envia parcialmente, com lag muito alto, ou tem campos faltantes em uma fração dos processos.

Tribunais com cobertura sólida: TJSP, TJRJ, TJMG, TJDFT, TJBA, TRF1, TRF3, TST, STJ. Tribunais com gaps relevantes em 2026: alguns TREs, JMUs, JMEs, e tribunais menores que ainda usam sistemas legados sem MNI implementado.

DataJud vs scraping — comparação direta

Aspecto	DataJud	Scraping (Vigilant)
Custo	Gratuito	R$ 0,10 por tribunal consultado
Autenticação	Não exige	API key Bearer
Busca por CPF/CNPJ	❌ Não suporta	✅ Suporta
Latência	30-90 dias	< 24h da última movimentação
Sintaxe	Elasticsearch DSL	REST simples (POST com JSON)
Schema	MNI unificado entre tribunais	MNI próximo + campos do tribunal
Peças/PDFs	❌ Não disponível	❌ Não disponível
SLA	Best effort, sem garantia	Documentado em contrato
Rate limit	~30 req/min (não oficial)	100 req/min (configurável)
Cache	Não, deve ser implementado pelo cliente	2 dias built-in (configurável)
Multi-tribunal em 1 chamada	❌ Por endpoint	✅ Lista de courts em 1 request
Suporte	Comunidade GitHub do CNJ	E-mail, Slack, account manager

Quando usar DataJud (e quando não)

Use DataJud quando:

• Você está fazendo pesquisa empírica ou análise estatística (e.g., “quantos processos de execução fiscal foram distribuídos no TJSP em 2024?”)
• Você consulta por número CNJ específico e a latência de 30-90 dias é aceitável
• Você está construindo dashboard público de transparência judicial
• Você precisa de dados massivos pra treinamento de modelos de ML (use o dump Parquet em vez da API)
• Custo é restrição absoluta e você aceita as limitações de cobertura

NÃO use DataJud quando:

• Você precisa buscar processos por CPF/CNPJ — a API não suporta
• Sua aplicação requer dados em tempo real (compliance, KYC, monitoramento)
• Você precisa SLA contratual — DataJud é best effort
• Sua aplicação é B2C com SLA de UX (latência sub-segundo) — DataJud responde em segundos
• Você precisa acesso a peças — DataJud só tem metadados (limitação compartilhada com scraping)

Caminho híbrido — usar os dois

Várias aplicações maduras combinam os dois:

• DataJud pra estatísticas agregadas (e.g., volume de processos por classe num período) — é mais barato e exatamente onde DataJud brilha
• Scraping pra consultas operacionais (e.g., listar todos os processos de um CPF) — onde DataJud não atende

Esse é o padrão usado por bureau de crédito e plataformas de monitoramento sérias. O ponto: não é uma escolha binária. Cada API tem seu caso de uso, e a arquitetura inteligente combina ambos com fallback.

Próximos passos

• Pra integrar a API Vigilant no seu pipeline (busca por CPF/CNPJ em tempo real), veja o post técnico API de consulta judicial: como automatizar pesquisa de processos.
• Pra entender as diferenças de sistema entre tribunais (ESAJ vs PJE vs outros), veja ESAJ vs PJE em 2026: Comparativo + Cobertura.
• Pra benchmarking entre alternativas, veja Vigilant vs JUDIT vs Escavador e Melhores APIs de consulta processual em 2026.
• Pra arquitetura específica por tribunal, /tribunais/ tem páginas dedicadas com peculiaridades de cada sistema.
• Documentação oficial DataJud: www.cnj.jus.br/sistemas/datajud.

DataJud é uma ferramenta excelente pra o que se propõe a fazer — agregação estatística e pesquisa pública. Pra produção operacional com requisitos de tempo real e busca por documento, ele é uma das peças do quebra-cabeça, não a solução completa. Avaliar honestamente as limitações antes de comprometer arquitetura é o que diferencia integrações que vão pra produção das que viram dor técnica seis meses depois.