API de Processos Judiciais no Brasil: Guia para Desenvolvedores 2026

Categoria: API e Tecnologia
Keyword principal: api processos judiciais
Keywords secundárias: api jurídica, dados judiciais api, monitoramento processual api, webhook processos judiciais
Persona: Dev / Tech Lead / CTO avaliando fornecedor de dados jurídicos
Funil: Meio/fundo (consideração e decisão)
Meta description: Guia técnico completo sobre APIs de processos judiciais no Brasil: como funcionam, fluxo assíncrono, exemplos de código, diferenças entre fontes públicas e privadas, e como a Judit resolve os principais gargalos de engenharia.

Integrar dados judiciais em um produto não é trivial. O judiciário brasileiro tem mais de 90 tribunais, cada um com sua estrutura, sistema e formato de resposta. Antes de escrever uma linha de código, é preciso entender como esse ecossistema funciona — e o que separa uma integração que escala de uma que quebra a cada trimestre.

Este guia é para desenvolvedores e times técnicos que precisam tomar essa decisão com clareza.

O que é uma API de processos judiciais

Uma API de processos judiciais é uma interface que permite que sistemas consultem, monitorem e recebam dados de processos em tramitação nos tribunais brasileiros, de forma programática e estruturada.

Em vez de acessar manualmente o portal de cada tribunal — com CAPTCHAs, inconsistências de layout e sessões que expiram — a aplicação faz uma requisição HTTP e recebe os dados em JSON padronizado, pronto para ser consumido por um motor de crédito, um CRM jurídico, um modelo de risco ou qualquer outro sistema downstream.

As principais operações que uma boa API jurídica precisa suportar são:

• Consulta por identificador — número CNJ, CPF, CNPJ, OAB ou nome da parte
• Retorno de andamentos — movimentações, decisões, despachos em ordem cronológica
• Acesso a documentos — petições, sentenças e despachos em PDF ou HTML diretamente do tribunal
• Monitoramento contínuo — alertas automáticos para novos andamentos via webhook
• Consulta em lote — processamento assíncrono de grandes volumes

O problema de construir isso internamente

A primeira pergunta que muitos times fazem é: por que não coletar diretamente dos tribunais?

A resposta é objetiva. Cada tribunal do Brasil tem uma arquitetura diferente. Há portais em PJe, eSAJ, PROJUDI, eProc, TUCUJURIS e pelo menos outros dez sistemas distintos. Manter scrapers ativos para todos eles exige uma equipe dedicada que não faz mais nada a não ser reagir às atualizações de interface, mudanças de CAPTCHA e instabilidades de infraestrutura dos próprios tribunais.

Um time de engenharia de produto perde em média 30–40% da capacidade quando resolve esse problema internamente — e o resultado ainda assim costuma ter cobertura parcial, com falhas silenciosas difíceis de detectar.

Para a maioria das empresas, isso não é o core business. É infraestrutura.

API pública do CNJ vs. APIs privadas

Existe uma opção gratuita e oficial: o DataJud, a API pública do Conselho Nacional de Justiça. Vale entender o que ela entrega e onde ela para.

O que o DataJud oferece

O DataJud centraliza metadados processuais de todos os tribunais que integram ao CNJ. É uma iniciativa relevante de transparência e serve bem para projetos acadêmicos, análises estáticas e prototipagem.

Onde ele não chega

Para uso em produção e escala, o DataJud tem limitações estruturais importantes:

Latência e atualização. Os dados são consolidados com periodicidade que pode chegar a dias ou semanas. Para decisões de crédito ou compliance em tempo real, isso é inviável.

Ausência de webhook. Não há mecanismo de notificação push. O sistema que quer monitorar processos precisa fazer polling constante.

Cobertura incompleta. Execuções penais, mandados de prisão via SEEU e outras fontes não estão disponíveis via DataJud.

Sem enriquecimento. A API retorna dados brutos na estrutura do tribunal de origem. Não há normalização cross-tribunal nem perfil litigioso agregado.

Rate limits restritivos. O uso em produção com volume expressivo de consultas esgota rapidamente os limites da API pública.

Para projetos que precisam de latência baixa, cobertura completa e confiabilidade de SLA, a alternativa é uma API privada especializada.

O que avaliar em uma API jurídica privada

Se você está avaliando fornecedores, estas são as dimensões técnicas que mais impactam a integração:

1. Cobertura de tribunais

O Brasil tem TJs estaduais, TRFs, TRTs e tribunais superiores (STF, STJ, TST). Uma API que não cobre todos eles força o time a manter integrações paralelas ou aceitar dados incompletos.

Pergunte ao fornecedor: qual é a cobertura de 1ª e 2ª instâncias por estado? Há acesso ao SEEU para execuções penais e mandados de prisão via BNMP?

2. Modelo assíncrono com webhook

A consulta a um tribunal envolve acesso a sistemas externos, parsing e normalização de dados — o que leva de segundos a minutos dependendo da disponibilidade do tribunal. Uma boa API opera de forma assíncrona: você submete a consulta, recebe um request_id e a resposta chega via webhook quando os dados estão prontos. Isso evita que a aplicação fique bloqueada esperando.

3. Cache inteligente

Para consultas repetidas ao mesmo processo, um cache com TTL configurável evita custo desnecessário de crawler e reduz a latência. O ideal é controlar quantos dias de validade do cache são aceitáveis para o seu caso de uso.

4. Padronização do schema

Cada tribunal retorna dados em formatos diferentes. Uma API de qualidade abstrai essa diversidade e entrega um schema consistente independentemente da fonte.

5. Suporte a MCP para agentes de IA

Se a sua empresa está construindo agentes de IA jurídicos, o suporte nativo a MCP (Model Context Protocol) elimina a necessidade de escrever integrações customizadas para conectar o modelo aos dados judiciais.

6. Rate limits e SLA

A Judit opera com limite padrão de 500 requisições por minuto, com limites personalizados disponíveis via contrato.

Como funciona a integração com a Judit API

Autenticação

Todas as chamadas usam o header api-key:

curl -H "api-key: SUA_API_KEY" https://requests.prod.judit.io/requests/

A chave é obtida com o time comercial da Judit. Armazene-a em variável de ambiente — nunca no código-fonte.

A arquitetura de serviços

A Judit API é composta por serviços especializados em hosts distintos:

• requests.prod.judit.io — criação de requisições e consulta de status
• lawsuits.prod.judit.io — acesso ao datalake de processos e download de anexos
• tracking.prod.judit.io — monitoramento contínuo de processos e documentos

O fluxo assíncrono de consulta

A consulta processual funciona em três passos:

Passo 1 — Criar a requisição

curl --location 'https://requests.prod.judit.io/requests/' \
  --header 'api-key: SUA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "search": {
      "search_type": "lawsuit_cnj",
      "search_key": "0009999-99.2024.8.26.0001"
    },
    "with_attachments": false
  }'

O retorno inclui um request_id — guarde-o para os próximos passos.

Passo 2 — Acompanhar o status

curl --location 'https://requests.prod.judit.io/requests/{request_id}' \
  --header 'api-key: SUA_API_KEY'

Aguarde até que o campo status seja "completed". Se você tiver um webhook configurado, este passo é desnecessário — a Judit entrega os dados diretamente no seu endpoint assim que estiverem prontos.

Passo 3 — Capturar os resultados

curl --location 'https://requests.prod.judit.io/responses?request_id={request_id}&page_size=100' \
  --header 'api-key: SUA_API_KEY'

O retorno é paginado e contém os processos encontrados dentro do array page_data.

Exemplo completo em JavaScript

const API_KEY = process.env.JUDIT_API_KEY;
const BASE_URL = 'https://requests.prod.judit.io';

async function consultarProcesso(numeroCNJ) {
  // Passo 1: cria a requisição
  const createRes = await fetch(`${BASE_URL}/requests/`, {
    method: 'POST',
    headers: {
      'api-key': API_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      search: {
        search_type: 'lawsuit_cnj',
        search_key: numeroCNJ
      }
    })
  });

  const { request_id } = await createRes.json();

  // Passo 2: polling até completar (use webhook em produção)
  let status = '';
  while (status !== 'completed') {
    await new Promise(r => setTimeout(r, 3000));
    const statusRes = await fetch(`${BASE_URL}/requests/${request_id}`, {
      headers: { 'api-key': API_KEY }
    });
    const data = await statusRes.json();
    status = data.status;
  }

  // Passo 3: busca os resultados
  const responsesRes = await fetch(
    `${BASE_URL}/responses?request_id=${request_id}&page_size=100`,
    { headers: { 'api-key': API_KEY } }
  );

  const { page_data } = await responsesRes.json();
  return page_data; // array de processos
}

import httpx, time, os

API_KEY = os.environ['JUDIT_API_KEY']
BASE_URL = 'https://requests.prod.judit.io'

def consultar_processo(numero_cnj: str):
    headers = {'api-key': API_KEY}

    # Passo 1: cria a requisição
    res = httpx.post(f'{BASE_URL}/requests/', headers=headers, json={
        'search': {'search_type': 'lawsuit_cnj', 'search_key': numero_cnj}
    })
    request_id = res.json()['request_id']

    # Passo 2: polling até completar (use webhook em produção)
    while True:
        time.sleep(3)
        status_res = httpx.get(f'{BASE_URL}/requests/{request_id}', headers=headers)
        if status_res.json()['status'] == 'completed':
            break

    # Passo 3: busca os resultados
    responses = httpx.get(
        f'{BASE_URL}/responses',
        headers=headers,
        params={'request_id': request_id, 'page_size': 100}
    )
    return responses.json()['page_data']

Cache inteligente

Para evitar custo desnecessário em consultas repetidas ao mesmo processo, use cache_ttl_in_days:

{
  "search": {
    "search_type": "lawsuit_cnj",
    "search_key": "0009999-99.2024.8.26.0001"
  },
  "cache_ttl_in_days": 1
}

Com esse parâmetro, se o processo já foi consultado nos últimos X dias, a Judit retorna os dados cacheados imediatamente — sem acionar o crawler.

Judit IA: resumo automático do processo

Para receber um resumo humanizado da capa e dos andamentos junto com os dados do processo, adicione o parâmetro judit_ia:

{
  "search": {
    "search_type": "lawsuit_cnj",
    "search_key": "0009999-99.2024.8.26.0001"
  },
  "judit_ia": ["summary"]
}

O resumo é entregue como um objeto adicional no array page_data, junto com os dados estruturados do processo.

Download de anexos processuais

Para baixar petições, sentenças e outros documentos, envie "with_attachments": true na criação da requisição. Os metadados dos arquivos chegam no campo attachments do processo. O download é feito via:

curl 'https://lawsuits.prod.judit.io/lawsuits/{numero_cnj}/{instancia}/attachments/{attachment_id}' \
  --header 'api-key: SUA_API_KEY'

Verifique o campo status do anexo antes de tentar o download — o valor deve ser "done". Os arquivos são entregues no formato original do tribunal: PDF, HTML, DOCX, JPG ou MP4 (para audiências gravadas).

Dados disponíveis no retorno

Um processo retornado pela Judit API inclui, entre outros campos:

{
  "code": "0009999-99.2024.8.26.0001",
  "tribunal_acronym": "TJSP",
  "instance": 1,
  "justice_description": "JUSTIÇA ESTADUAL",
  "area": "DIREITO CIVIL",
  "status": "Ativo",
  "phase": "Inicial",
  "distribution_date": "2024-03-15T00:00:00.000Z",
  "amount": 45000.00,
  "classifications": [{ "code": "7", "name": "PROCEDIMENTO COMUM CÍVEL" }],
  "subjects": [{ "code": "10431", "name": "RESPONSABILIDADE CIVIL" }],
  "parties": [
    {
      "side": "Active",
      "name": "Empresa Credora S/A",
      "person_type": "Autor",
      "main_document": "00000000000000",
      "documents": [{ "document": "00000000000000", "document_type": "CNPJ" }]
    }
  ],
  "last_step": {
    "step_id": "abc12345",
    "step_date": "2026-04-10T14:30:00.000Z",
    "content": "Conclusos para decisão/despacho",
    "steps_count": 7
  },
  "steps": [ ... ],
  "attachments": [ ... ]
}

O schema é consistente independentemente do tribunal de origem. A normalização acontece na camada da Judit.

Casos de uso mais comuns

Motor de crédito e onboarding de PJ

No momento do cadastro de um CNPJ, a aplicação dispara uma requisição assíncrona. O webhook entrega o perfil litigioso completo da empresa — execuções fiscais em aberto, recuperações judiciais, ações trabalhistas — antes da aprovação de crédito.

Background check em RH

O fluxo de seleção integra a consulta de CPF do candidato. O retorno inclui mandados de prisão ativos via BNMP e execuções penais via SEEU — com cobertura nacional.

Monitoramento de carteira

Escritórios e departamentos jurídicos cadastram processos para monitoramento contínuo. Cada novo andamento relevante gera um alerta automático no webhook, eliminando a consulta manual diária.

Enriquecimento de dados para modelos de ML

Times de data science consomem a API em lote para enriquecer datasets com features judiciais — número de processos como réu, valor total de execuções, distribuição por área do direito — usados como inputs em modelos de score de risco.

Primeiros passos

Para começar a usar a Judit API:

1. Explore os endpoints na documentação
2. Importe a Collection para Postman para testar os endpoints sem escrever código
3. Configure um webhook de teste com Webhook.site para inspecionar os payloads reais antes de implementar

Conclusão

Integrar dados judiciais ao produto certo pode ser um diferencial competitivo real — mas a qualidade da integração depende diretamente da qualidade da infraestrutura escolhida.

Os pontos que mais afetam a decisão na prática: cobertura de tribunais, modelo assíncrono com webhook, cache configurável, padronização do schema e SLA de disponibilidade.

Para times que querem ir de zero a dados judiciais em produção sem montar uma equipe de scraping, a Judit API foi construída exatamente para isso.

Publicado em: abril de 2026 — Atualizado a cada trimestre