Pular para o conteúdo principal
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).
request_status
string
Status final da resposta (Deve ser completed).
page
integer
Página atual da busca.
page_count
integer
Total de processos renderizados nesta página.
all_count
integer
Total absoluto de processos encontrados e vinculados ao documento.
all_pages_count
integer
Quantidade total de páginas disponíveis.
page_data
array
Array de objetos. Cada objeto contém a chave response_data que abriga a Capa do Processo.