Skip to main content
Novo CNPJ (IN 2229/24)A Judit já aceita o novo formato de CNPJ alfanumérico em conformidade com a Instrução Normativa RFB nº 2229/2024.
  • Zero esforço: nenhuma alteração é necessária na sua integração.
  • Ambiente de teste: utilize o documento A1B2C3D4/E5F6-68 para validar o fluxo e receber um processo fictício de resposta.
Resposta em cache (cached_response)Quando você cria uma consulta processual ou histórica, a Judit primeiro verifica se o dado já está em nossa base. Se estiver, devolvemos imediatamente o resultado — tanto na resposta da API quanto via webhook (se você tiver cadastrado) — com o campo cached_response: true.Em paralelo, a Judit dispara uma atualização nos tribunais. Se houver alguma mudança, você recebe uma segunda resposta com cached_response: false. Esse é o resultado mais atual.Por isso, é normal receber dois webhooks aparentemente iguais para o mesmo request_id:
  • O primeiro vem do cache (cached_response: true)
  • O último é o atualizado (cached_response: false)
Use esse campo para identificar com precisão qual retorno representa o estado mais recente do processo.
A Consulta Histórica por Documento retorna toda a carteira processual vinculada a um CPF, CNPJ, OAB ou Nome. É o caminho ideal para due diligence, KYC, mapeamento de exposição judicial e qualquer cenário em que você precise saber quais processos existem (capa + partes), sem necessariamente entrar em cada um.
Esta página documenta exclusivamente o fluxo Assíncrono de consulta histórica. O cliente deve fazer um POST /requests, aguardar o processamento (GET /requests/{id}) e resgatar os dados no GET /responses. A resposta da Consulta Histórica retorna um array paginado contendo exclusivamente a Capa e as Partes do processo (omitindo andamentos, anexos, fase e status). É possível filtrar os resultados tanto no payload do POST inicial quanto nas query strings do GET final.

Quando usar

Due diligence / KYC

Antes de fechar contrato, descubra todo o passivo judicial da contraparte por CPF/CNPJ.

Crédito e cobrança

Combine com filtros (amount_gte, side: "Passive") para priorizar abordagens com base no valor de causa.

Vigilância de carteira

Cruze com Monitoramento por documento para detectar novos processos após a consulta inicial.

Inteligência por OAB

Consulte por OAB para listar todos os processos em que um advogado atua.

Síncrono vs. Assíncrono

Antes de integrar, é fundamental entender a diferença de arquitetura que a Judit oferece para este endpoint:
  • Consulta Síncrona (Datalake Hotstorage): A resposta com todos os processos é devolvida instantaneamente no corpo (body) do próprio POST. Não exige checagem de status. Ideal para fluxos sensíveis à latência da resposta como onboardings. Veja a documentação Síncrona aqui.
  • Consulta Assíncrona (Datalake / On-Demand): É o fluxo que abordaremos nesta página. Busca em múltiplas fontes externas ou diretamente nos tribunais (On-Demand) em tempo real. Exige um fluxo de 3 etapas (Criar -> Checar -> Consumir).

Passo 1: Criar a Requisição de Busca (POST)

Para iniciar o fluxo assíncrono, faça uma requisição POST informando o documento desejado. POST https://requests.production.judit.io/requests

Exemplos de consultas históricas

Ao realizar consultas por nome, é possível que existam homônimos (pessoas ou empresas com o mesmo nome). Recomendamos que, sempre que possível, utilize identificadores únicos, como CPF ou CNPJ, para garantir maior precisão nos resultados.

Parâmetros Base do Payload

Sobre o uso da customer_key: Esta credencial só terá efeito se o parâmetro on_demand for igual a true. Ao informá-la, a Judit acessará os tribunais de forma autenticada, permitindo a captura de processos em segredo de justiça aos quais o dono da credencial (advogado) esteja previamente vinculado ao respectivo processo.

Filtros Prévios da Requisição (search_params.filter)

Você pode restringir a busca inicial enviando o objeto filter dentro de search_params no corpo (body) do seu POST. Isso é altamente recomendado, pois evita que o robô perca tempo processando varas ou tribunais de estados ou anos que não importam para o seu negócio. Abaixo, detalhamos como construir cada filtro passo a passo.

1. Filtros de Polo e Valor da Causa

Permite buscar processos onde a pessoa processou alguém, foi processada, ou filtrar por valores em reais.
  • side (string): De qual lado do processo o documento buscado está?
    • "Active" (Autor da ação)
    • "Passive" (Réu na ação)
    • "Interested" (Terceiro interessado)
    • "Unknown" (Polo não identificado)
  • amount_gte (number): Valor da causa Maior ou Igual a (GTE = Greater Than or Equal).
  • amount_lte (number): Valor da causa Menor ou Igual a (LTE = Less Than or Equal).

2. Filtros de Tribunal (A Regra de Inclusão e Exclusão)

Para filtrar por estados ou tribunais específicos, usamos o objeto tribunals. Ele exige duas informações: a lista de siglas (keys) e uma regra de negação (not_equal).

Lista de Tribunais Aceitos (Filtros)

Utilize as siglas exatas da coluna Sigla (Key) abaixo quando for realizar filtros por tribunais (ex: no parâmetro tribunals.keys).
  • Inclusão: Se not_equal for false, a API vai buscar APENAS nos tribunais da lista.
  • Exclusão: Se not_equal for true, a API vai buscar no Brasil inteiro, EXCETO nos tribunais da lista.

Exemplo JSON: Inclusão vs. Exclusão de Tribunais

3. Filtros de Assunto e Classe (Padrão CNJ)

A Judit API utiliza as Tabelas Processuais Unificadas (TPU) oficiais do Conselho Nacional de Justiça (CNJ). Você pode filtrar processos inserindo os códigos numéricos exatos dessas tabelas. 👉 Para descobrir os códigos oficiais de Classes e Assuntos, acesse a Consulta Pública do SGT/CNJ. A mecânica de filtro funciona da seguinte forma:
  • Assuntos (subject_codes): Usa as listas contains (Quero processos que contenham estes códigos) e not_contains (Não quero processos que contenham estes códigos).
  • Classes (classification_codes): Usa a lista keys e a regra not_equal (a mesma lógica de inclusão/exclusão dos tribunais).

4. Filtros de Datas e Prazos

Otimize a busca por recortes de tempo usando o formato universal de datas (ISO 8601: AAAA-MM-DDTHH:mm:ss.sssZ).
  • distribution_date_gte (string): Traz processos distribuídos (iniciados) a partir de uma data.
  • last_step_date_gte (string): Traz processos cuja última movimentação ocorreu a partir de uma data.
  • last_step_date_lte (string): Traz processos cuja última movimentação ocorreu antes de uma data.

5. Filtros Restritivos de Outras Partes

Quer saber se o João processou a Empresa X? Você pode usar os filtros de Nomes e Documentos de outras partes envolvidas no processo.
  • party_names (array de strings): Lista de nomes exatos que devem constar no processo.
  • party_documents (array de strings): Lista de CPFs/CNPJs que devem constar no processo.
Atenção ao usar junto com o filtro side: Se você usar o filtro party_names ou party_documents junto com o filtro side, a regra de “Polo” (Autor/Réu) será aplicada apenas ao documento principal que você está pesquisando, e não aos nomes/documentos extras listados aqui.

Exemplo de Requisição (POST)

Guarde o request_id (ex: 05ee9825...) gerado na resposta desta chamada. Ele é o seu passaporte para os próximos passos.
🚀 Atalho: Automatize com Webhooks (Recomendado)Se você possui uma URL de Webhook configurada, os Passos 2 e 3 abaixo são totalmente opcionais. Em vez de programar sua aplicação para ficar perguntando o status da requisição, a Judit API enviará os processos encontrados de forma incremental diretamente para o seu servidor assim que eles forem capturados, finalizando o fluxo com um evento de request_completed.👉 Aprenda a configurar e receber Webhooks aqui

Passo 2: Consultar o Status da Requisição

Como um documento pode estar atrelado a centenas de processos no Brasil, a coleta leva tempo. Você deve consultar o status macro da requisição usando o ID do Passo 1. GET https://requests.production.judit.io/requests/<REQUEST_ID>
cURL (Passo 2)
Você deve realizar polling (consultas periódicas) nesta rota até que a propriedade "status" mude de "pending" para "completed". (Nota: O uso de Webhooks elimina a necessidade deste passo).

Verificação Granular (Apenas para On-Demand)

Como a busca On-Demand consulta dezenas de sistemas simultaneamente, você pode acompanhar o status individual de cada tribunal acessado usando a rota de Crawls:
cURL

Passo 3: Consumir e Filtrar os Resultados (GET)

Assim que o status no Passo 2 retornar "completed", os dados estão prontos! É aqui, na rota GET /responses, que você puxa o JSON final. A grande sacada deste endpoint é que ele permite aplicar filtros dinâmicos via URL (Query Params), permitindo que você fatie, ordene e pagine a resposta final do jeito que quiser, sem precisar gerar uma nova requisição (POST). GET https://requests.production.judit.io/responses/

Filtros Dinâmicos na URL (Query Params)

Estes são os parâmetros que você pode concatenar na sua requisição final:

O formato da Resposta

O retorno traz as chaves de paginação e o array page_data, onde cada objeto contém a response_data (A Capa do Processo).
string
Status final da resposta (Deve ser completed).
integer
Página atual da busca.
integer
Total de processos renderizados nesta página.
integer
Total absoluto de processos encontrados e vinculados ao documento.
integer
Quantidade total de páginas disponíveis.
array
Array de objetos. Cada objeto contém a chave response_data que abriga a Capa do Processo.