Dados judiciais como feature se tornaram um diferencial competitivo real em produtos B2B. CRMs que mostram o passivo judicial do cliente, ERPs que verificam fornecedores automaticamente no onboarding, plataformas de RH que checam antecedentes em escala — todas essas funcionalidades dependem de uma única infraestrutura: acesso estruturado ao judiciário brasileiro.

O problema é que construir isso internamente não faz sentido para a maioria das empresas.

Dados judiciais como feature nativa: da fonte ao produto SaaS em uma única integração via API

Este artigo é para CTOs e PMs que querem adicionar dados judiciais ao produto sem montar uma equipe de coleta de dados do zero.

Quais features de dados judiciais são possíveis via API

Antes de entrar na implementação, vale mapear o que a Judit API permite construir:

Score jurídico de entidades — retorno sintético com contagem de processos, distribuição por área do direito, fase processual e polo — pronto para alimentar um modelo de risco ou exibir em um painel.

Background check de CPF/CNPJ — histórico processual completo com dados cadastrais da Receita Federal integrados, mandados de prisão e execuções penais, em uma única chamada.

Due diligence de fornecedores e parceiros — verificação judicial automatizada no fluxo de onboarding, sem depender de consulta manual.

Monitoramento contínuo de carteira — alertas automáticos via webhook quando um cliente, devedor ou parceiro tem nova movimentação processual.

Enriquecimento de leads — dados cadastrais (endereço, contatos, QSA) e perfil litigioso de CNPJs diretamente no CRM, sem saída do sistema.

Cada uma dessas features corresponde a um endpoint ou combinação de endpoints da Judit API. Vamos ver como implementar cada uma.

1. Score jurídico com consulta agrupada

A consulta agrupada é o endpoint mais eficiente para exibir um resumo do perfil litigioso de uma entidade — ideal para dashboards e painéis de risco.

Em vez de retornar todos os processos individualmente, ela devolve contagens agrupadas por área do direito, tribunal, fase processual, polo e estado, com uma única requisição síncrona.

curl --location 'https://lawsuits.production.judit.io/requests/create/grouped' \
  --header 'api-key: SUA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "search": {
      "search_type": "cnpj",
      "search_key": "00.000.000/0001-00"
    }
  }'

A resposta inclui:

{
  "lawsuits_count": 27,
  "areas": [
    { "count": 12, "value": "DIREITO DO TRABALHO" },
    { "count": 8,  "value": "DIREITO CIVIL" },
    { "count": 4,  "value": "DIREITO TRIBUTÁRIO" }
  ],
  "phases": [
    { "count": 14, "value": "INICIAL" },
    { "count": 9,  "value": "ARQUIVADO" },
    { "count": 4,  "value": "TRÂNSITO EM JULGADO OU ACORDO" }
  ],
  "sides": [
    { "count": 19, "value": "PASSIVE" },
    { "count": 8,  "value": "ACTIVE" }
  ],
  "tribunals": [
    { "count": 12, "value": "TRT1" },
    { "count": 8,  "value": "TJRJ" },
    { "count": 4,  "value": "TRF2" }
  ],
  "states": [
    { "count": 20, "value": "RJ" },
    { "count": 7,  "value": "SP" }
  ]
}

Com esses dados é possível construir um score jurídico customizado para o contexto do seu produto — por exemplo, uma fintech pode ponderar processos em que a entidade é passiva em execuções fiscais de forma diferente de uma empresa de RH que se importa mais com mandados de prisão ativos.

Exemplo: card de risco jurídico em um CRM

async function buscarPerfilJuridico(cnpj) {
  const res = await fetch(
    'https://lawsuits.production.judit.io/requests/create/grouped',
    {
      method: 'POST',
      headers: {
        'api-key': process.env.JUDIT_API_KEY,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify({
        search: { search_type: 'cnpj', search_key: cnpj }
      })
    }
  );

  const perfil = await res.json();

  return {
    total: perfil.lawsuits_count,
    comoPassivo: perfil.sides.find(s => s.value === 'PASSIVE')?.count ?? 0,
    trabalhistas: perfil.areas.find(a => a.value === 'DIREITO DO TRABALHO')?.count ?? 0,
    tributarios: perfil.areas.find(a => a.value === 'DIREITO TRIBUTÁRIO')?.count ?? 0,
    emAndamento: perfil.phases.find(p => p.value === 'INICIAL')?.count ?? 0,
  };
}

import httpx, os

def buscar_perfil_juridico(cnpj: str) -> dict:
    res = httpx.post(
        'https://lawsuits.production.judit.io/requests/create/grouped',
        headers={'api-key': os.environ['JUDIT_API_KEY']},
        json={'search': {'search_type': 'cnpj', 'search_key': cnpj}}
    )
    perfil = res.json()

    def count(lst, key, val):
        return next((i['count'] for i in lst if i['value'] == val), 0)

    return {
        'total': perfil['lawsuits_count'],
        'como_passivo': count(perfil['sides'], 'value', 'PASSIVE'),
        'trabalhistas': count(perfil['areas'], 'value', 'DIREITO DO TRABALHO'),
        'tributarios': count(perfil['areas'], 'value', 'DIREITO TRIBUTÁRIO'),
        'em_andamento': count(perfil['phases'], 'value', 'INICIAL'),
    }

2. Enriquecimento cadastral com dados da Receita Federal

Para exibir dados completos de um CPF ou CNPJ — endereço, contatos, QSA, atividade principal — a Judit integra diretamente com a Receita Federal via o endpoint de dados cadastrais.

O campo response_type: "entity" na requisição ativa esse retorno:

# Consulta de CNPJ com dados cadastrais
curl --location 'https://lawsuits.prod.judit.io/requests/create' \
  --header 'api-key: SUA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "search": {
      "search_type": "cnpj",
      "search_key": "00.000.000/0001-00",
      "response_type": "entity"
    }
  }'

Para dados em tempo real diretamente da Receita Federal (em vez do datalake), adicione "on-demand": true:

{
  "search": {
    "search_type": "cnpj",
    "search_key": "00.000.000/0001-00",
    "response_type": "entity"
  },
  "on-demand": true
}

A resposta de um CNPJ inclui:

{
  "has_lawsuits": true,
  "response_data": [{
    "entity_type": "company",
    "main_document": "00.000.000/0001-00",
    "name": "EMPRESA EXEMPLO S/A",
    "social_name": "EXEMPLO",
    "addresses": [{ "street": "...", "city": "São Paulo", "state": "SP" }],
    "contacts": [
      { "description": "11999999999", "contact_type": "phone" },
      { "description": "contato@empresa.com.br", "contact_type": "email" }
    ],
    "partners": [
      {
        "name": "SÓCIO EXEMPLO",
        "position": "DIRETOR",
        "tags": { "start_date": "2019-03-01T00:00:00.000Z" }
      }
    ],
    "branch_activities": [
      { "code": "6499999", "name": "ATIVIDADES DE SERVIÇOS FINANCEIROS", "main_activity": true }
    ],
    "legal_nature": { "code": "2046", "name": "SOCIEDADE ANÔNIMA ABERTA" },
    "special_status": "RECUPERACAO JUDICIAL",
    "special_status_date": "2023-06-29T00:00:00.000Z",
    "share_capital": 50000000,
    "revenue_service_active": true
  }]
}

O campo has_lawsuits é útil como gatilho rápido: se true, vale disparar a consulta processual completa. Se false, o onboarding pode seguir sem bloqueio.

Também é possível revelar os documentos dos sócios sem mascaramento adicionando "reveal_partners_documents": true ao payload — útil para due diligence de alto valor onde a identificação dos sócios é necessária.

3. Background check no fluxo de onboarding

Para plataformas que precisam verificar juridicamente uma entidade no momento do cadastro, a combinação mais eficiente é:

1. Consulta agrupada síncrona — resposta imediata com o perfil litigioso para exibição instantânea
2. Consulta assíncrona completa com webhook — dados aprofundados entregues em background enquanto o usuário continua o fluxo

Isso garante que o onboarding não trava aguardando o crawler, mas os dados completos chegam assim que disponíveis.

async function onboardingJuridico(cnpj) {
  // Etapa 1: score rápido (síncrono) — exibe imediatamente no UI
  const score = await buscarPerfilJuridico(cnpj);
  await exibirCardRiscoUI(score);

  // Etapa 2: consulta completa (assíncrona) — entregue via webhook
  await fetch('https://requests.prod.judit.io/requests/', {
    method: 'POST',
    headers: {
      'api-key': process.env.JUDIT_API_KEY,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      search: { search_type: 'cnpj', search_key: cnpj },
      callback_url: process.env.WEBHOOK_URL
    })
  });
  // Dados completos chegam no webhook quando o crawler terminar
}

4. Monitoramento contínuo de clientes e parceiros

Para produtos que precisam alertar o usuário quando algo muda juridicamente em uma empresa ou pessoa monitorada, o endpoint de tracking registra o acompanhamento e envia um webhook a cada nova movimentação.

A lógica de registro é simples — detalhada no artigo sobre webhooks e monitoramento:

curl --location 'https://tracking.prod.judit.io/tracking/document' \
  --header 'api-key: SUA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
    "recurrence": 1,
    "search": {
      "search_type": "cnpj",
      "search_key": "00.000.000/0001-00"
    },
    "callback_url": "https://seu-produto.com/webhooks/judit"
  }'

A cada ciclo de recorrência, o crawler verifica se há novas ações distribuídas contra o CNPJ. Quando há, o payload com o processo completo chega no webhook configurado.

5. Arquitetura recomendada para SaaS

Para um produto SaaS que usa dados judiciais como feature com múltiplos clientes e alto volume de consultas, a arquitetura que funciona melhor em produção é:

[Seu produto] → [Fila de consultas] → [Judit API] → [Webhook handler] → [Banco de dados] → [Seu produto]

Por que usar uma fila entre o produto e a API? A consulta jurídica é assíncrona e o resultado pode demorar de segundos a minutos. Colocar uma fila entre o gatilho (usuário faz onboarding) e a chamada à API desacopla a experiência do usuário do tempo de processamento.

Cache de resultados no seu banco. Resultados de consultas recentes não precisam ser reprocessados. Salve o resultado com um TTL configurável — para onboarding, 7 dias costuma ser suficiente; para monitoramento de risco ativo, 1 dia.

Separação de responsabilidades no webhook handler. O handler deve apenas salvar o payload e enfileirar para processamento — não executar lógica de negócio inline. Isso garante resposta rápida para a Judit e evita perda de dados em caso de erro.

// Handler minimalista — apenas salva e enfileira
app.post('/webhooks/judit', async (req, res) => {
  // Salva o payload bruto antes de qualquer processamento
  await db.rawCallbacks.insert({
    payload: req.body,
    received_at: new Date()
  });

  // Enfileira para processamento assíncrono
  await queue.add('processar-retorno-judicial', { callbackId: req.body.callback_id });

  res.status(200).json({ ok: true });
});

Considerações para white-label

Se o seu produto revende a funcionalidade de verificação judicial para os seus próprios clientes — sem que eles saibam que a Judit está por baixo — o modelo white-label funciona da seguinte forma:

Uma única API key gerencia todos os seus clientes. Você controla o acesso, cobra pelo uso conforme sua política de preços, e entrega a feature com a identidade visual do seu produto.

Use tags para segregar por cliente. O endpoint de criação de requisições aceita um campo tags livre que você pode usar para associar cada consulta a um cliente interno:

{
  "search": {
    "search_type": "cnpj",
    "search_key": "00.000.000/0001-00"
  },
  "tags": {
    "cliente_id": "cli_abc123",
    "produto": "onboarding_pj"
  }
}

Isso facilita a reconciliação de consumo por cliente no relatório de uso disponível em https://requests.prod.judit.io — importante para faturamento interno.

O que você não precisa construir ao usar dados judiciais via API

Quando a Judit API é a infraestrutura, estas são as responsabilidades que saem do seu time de engenharia:

• Scrapers e manutenção de cobertura de tribunais
• Normalização de schemas entre sistemas judiciais distintos
• Infraestrutura de armazenamento e atualização de dados processuais
• Integração com Receita Federal para dados cadastrais
• Acesso ao BNMP (mandados de prisão) e SEEU (execuções penais)
• Atualizações decorrentes de mudanças nos portais dos tribunais

O que fica com o seu time é a lógica de negócio — quando bloquear, alertar, exibir, pontuar — que é exatamente onde o valor do seu produto está.

Próximos passos

Para integrar dados jurídicos ao seu produto:

Publicado em: abril de 2026 — Atualizado a cada trimestre