Cofre de Credenciais para Tribunais - JUDIT

O Cofre de Credenciais guarda, criptografadas, as credenciais (CPF/OAB + senha) que advogados usam para se autenticar em tribunais brasileiros. Com isso, a Judit pode acessar processos sob segredo de justiça em nome do advogado, sem que sua aplicação precise jamais armazenar ou trafegar a senha.

🤖 Endpoint base: https://crawler.production.judit.io/credentials. Cadastre uma vez por sistema/tribunal e referencie depois nas consultas via credential.customer_key.

Quando usar

Acesso a processos sob segredo

Necessário para consultar processos cíveis e trabalhistas restritos.

Multi-tenant para escritórios

Use customer_key para separar credenciais por advogado/cliente do escritório.

Conformidade LGPD

Senhas são armazenadas criptografadas em cofre dedicado — sua aplicação nunca transita a senha.

Credencial coringa

Cadastre "system_name": "*" como fallback para tribunais sem credencial específica.

Certificado digital A1

Tribunais que só aceitam login por certificado usam a rota POST /credentials/certificate.

Antes de cadastrar no Cofre: cadastro no tribunal

Antes de cadastrar uma credencial no Cofre de Credenciais, é necessário que essa credencial já exista no tribunal correspondente. A Judit não cria usuários, senhas ou permissões dentro dos sistemas dos tribunais. O cadastro deve ser realizado diretamente no portal do tribunal pelo cliente, advogado, escritório ou responsável autorizado. Após a criação ou validação da credencial no tribunal, ela poderá ser cadastrada no Cofre de Credenciais da Judit e associada a uma chave de identificação chamada customer_key.

A customer_key não é a senha do tribunal. Ela é apenas uma chave de referência utilizada para selecionar, dentro do Cofre de Credenciais, qual credencial deve ser usada na consulta.

Fluxo de cadastro e uso

Permissões da credencial no tribunal

O retorno da consulta autenticada depende diretamente das permissões da credencial cadastrada no próprio tribunal. Isso significa que a Judit só conseguirá acessar processos, documentos, anexos ou movimentações que estejam disponíveis para aquele usuário no portal do tribunal. Por exemplo:

se a credencial possui acesso ao processo, a consulta poderá retornar dados autenticados;
se a credencial não possui permissão no tribunal, a consulta poderá retornar apenas dados públicos ou não conseguir acessar o conteúdo protegido;
se o processo estiver em segredo de justiça, o acesso dependerá das permissões concedidas à credencial no sistema do tribunal.

Cadastrar uma credencial no Cofre não garante, por si só, acesso a processos sigilosos ou documentos restritos. O acesso sempre depende das permissões existentes no tribunal.

Autenticação em dois fatores

Alguns tribunais podem exigir autenticação em dois fatores, também conhecida como 2FA, MFA, token, código por e-mail, SMS, aplicativo autenticador ou certificado digital. Quando isso acontece, o comportamento pode variar conforme a regra de autenticação do próprio tribunal. Em geral:

se o tribunal exigir o segundo fator apenas no primeiro acesso ou em intervalos específicos, a credencial poderá funcionar após a validação inicial;
se o tribunal exigir o segundo fator a cada novo login, a consulta autenticada poderá depender de uma etapa adicional de validação;
se o código de autenticação expirar rapidamente ou exigir ação manual recorrente, a execução automatizada poderá ser impactada.

Se o tribunal exigir certificado digital, o cadastro é feito por uma rota específica do Cofre. Veja Cadastro de credencial com certificado digital (A1).

Tribunais com autenticação em dois fatores podem aumentar o tempo de execução da consulta ou exigir validações adicionais. Nesses casos, o suporte da Judit deve ser acionado para avaliar a viabilidade operacional do uso da credencial.

Como obter o segredo 2FA para cadastro no Cofre

Em tribunais que exigem autenticação em dois fatores por aplicativo autenticador, como Google Authenticator, Microsoft Authenticator, Authy ou similares, é necessário cadastrar no Cofre o segredo 2FA da credencial. Esse segredo também pode ser identificado como secret, secrecy, chave secreta, chave manual ou chave de configuração, dependendo do sistema utilizado.

Não cadastre o código temporário de 6 dígitos no campo de 2FA.
Esse código muda a cada poucos segundos e não deve ser usado como segredo da credencial.

Diferença entre segredo 2FA e código temporário

Informação	O que é	Deve ser cadastrado no Cofre?
Segredo 2FA	Chave fixa usada para gerar os códigos temporários	Sim
Código temporário	Código de 6 dígitos gerado pelo aplicativo autenticador	Não

Como identificar o segredo 2FA

Durante a configuração do 2FA no portal do tribunal, normalmente o tribunal exibe um QR Code para ser lido por um aplicativo autenticador. Além do QR Code, alguns tribunais também exibem uma opção como:

Não consigo ler o QR Code
Inserir chave manualmente
Exibir chave secreta
Chave de configuração
Secret key
Setup key

A chave exibida nessa etapa é o segredo 2FA que deve ser cadastrado no Cofre de Credenciais.

O segredo 2FA geralmente é uma sequência alfanumérica maior que um código comum, podendo conter letras e números.
Exemplo meramente ilustrativo: JBSWY3DPEHPK3PXP

Fluxo recomendado para cadastro com 2FA

O que cadastrar no Cofre

Ao cadastrar uma credencial com autenticação em dois fatores, informe:

usuário/login do tribunal;
senha do tribunal;
customer_key desejada para identificar a credencial;
segredo 2FA, quando o tribunal exigir autenticação por aplicativo autenticador.

O segredo 2FA deve ser a chave fixa de configuração do autenticador, e não o código temporário gerado pelo aplicativo.

Caso o 2FA já esteja configurado

Se o 2FA já tiver sido configurado anteriormente e o tribunal não exibir mais a chave secreta, normalmente não é possível recuperar o segredo diretamente pelo aplicativo autenticador. Nesse cenário, o caminho recomendado é:

acessar o portal do tribunal com a credencial;
remover, redefinir ou reconfigurar a autenticação em dois fatores;
iniciar uma nova configuração de 2FA;
copiar a chave manual ou segredo exibido no momento da configuração;
cadastrar esse segredo no Cofre de Credenciais.

Cada tribunal pode ter um fluxo diferente para redefinição do 2FA. Caso o portal não permita visualizar ou reconfigurar o segundo fator, será necessário acionar o suporte do próprio tribunal ou o responsável pela credencial.

Boas práticas para cadastro de credenciais

Recomendamos que as credenciais cadastradas no Cofre sejam:

credenciais institucionais ou de serviço, quando permitido pelo tribunal;
criadas com permissões compatíveis com os processos que precisam ser consultados;
validadas previamente no portal do tribunal antes do uso via API;
mantidas atualizadas sempre que houver troca de senha ou alteração de acesso;
configuradas com um método de autenticação em dois fatores compatível com a operação automatizada, quando aplicável.

Caso a senha seja alterada, a credencial expire ou o tribunal solicite uma nova validação de acesso, será necessário atualizar ou revalidar a credencial no Cofre para manter a consulta funcionando corretamente.

Como selecionar a credencial no payload da requisição

Para utilizar uma credencial cadastrada no Cofre de Credenciais durante a consulta, informe o campo customer_key dentro de search.search_params.credential. O valor de customer_key deve corresponder à chave da credencial previamente cadastrada no Cofre.

A consulta será executada utilizando a credencial associada à customer_key informada no payload.

Exemplo de requisição

curl --location 'https://requests.prod.judit.io/requests/' \
--header 'Content-Type: application/json' \
--header 'api-key: <api-key>' \
--data '{
    "search": {
        "search_type": "lawsuit_cnj",
        "search_key": "0000000-00.0000.0.00.0000",
        "search_params": {
            "credential": {
                "customer_key": "CUSTOMER-KEY"
            }
        }
    }
}'

Caso a customer_key informada não exista, esteja inválida ou esteja vinculada a uma credencial expirada, a consulta poderá falhar ou não utilizar a credencial esperada.

Rota para cadastrar suas chaves no cofre de credenciais

Para começar a utilizar o cofre de credeniais, você deve realizar uma solicitação POST para a rota crawler.production.judit.io/credentials e cadastrar as credenciais dos advogados nos respectivos tribunais disponibilizados.

Payload da Solicitação

A solicitação POST deve incluir um payload com as seguintes propriedades:

system_name: A sigla do tribunal e sistema que será cadastrado a nova credencial.
- Obs: Poderá ser cadastrada uma credencial coringa "system_name": "*". Se uma credencial for cadastrada nela, todos os tribunais que não tiverem outra credencial cadastrada utilizarão a credencial coringa.
customer_key: Identificador personalizado para associar a credencial a um cliente ou advogado. Pode ser qualquer nome ou rótulo definido pelo responsável pelo cadastro, facilitando a organização e o gerenciamento das credenciais.
username: CPF (Cadastro de Pessoas Físicas) ou número da OAB (Ordem dos Advogados do Brasil), conforme exigido pelo sistema do tribunal onde o login será realizado.
password: Senha cadastrada no respectivo tribunal.

Propriedades necessárias apenas nos casos de tribunais que exigem autenticação de dois fatores:

custom_data: Objeto opcional destinado a armazenar informações adicionais específicas para o sistema ou contexto de uso. Pode incluir campos personalizados como, por exemplo, um secret necessário para autenticação ou outras configurações específicas.
secret: Token de autenticação de dois fatores do sistema a ser cadastrado.

Obs: As credenciais cadastradas são criptografadas, garantindo a segurança dos dados, e não podem ser acessadas posteriormente. Para modificar informações já cadastradas, basta criar um novo registro utilizando o mesmo customer_key e o mesmo system_name. O novo cadastro substituirá automaticamente a credencial existente. Exemplo de payload para cadastro de credenciais sem autenticação de dois fatores:

{
  "credentials": [
    {
      "system_name": "PJE TJBA - 1º grau",
      "customer_key": "00000001",
      "username": "999.999.999-99",
      "password": "Senha123"
    },
    {
      "system_name": "ESAJ - TJAC - 1º grau",
      "customer_key": "00000002",
      "username": "999.999.999-99",
      "password": "Senha123"
    }
  ]
}

Exemplo de payload para cadastro de credenciais com autenticação de dois fatores:

{
  "credentials": [
    {
      "system_name": "PJE TJBA - 1º grau",
      "customer_key": "00000001",
      "username": "999.999.999-99",
      "password": "Senha123",
      "custom_data": {
				"secret": "<TOKEN>"
			}
    }
  ]
}

Exemplo de resposta a solicitação:

[
    {
        "system_name": "ESAJ - TJAC - 1º grau",
        "message": "CREDENTIAL_CREATED"
    },
    {
        "system_name": "PJE TJBA - 1º grau",
        "message": "CREDENTIAL_CREATED"
    }
]

Cadastro de credencial com certificado digital (A1)

Alguns tribunais não aceitam login por CPF/OAB + senha e exigem certificado digital. Para esses casos, o Cofre de Credenciais possui uma rota separada, exclusiva para upload de certificado: POST /credentials/certificate.

O certificado não pode ser enviado pela rota POST /credentials. Se você tentar colocar o certificado dentro de custom_data, a API responde com o erro CERTIFICATE_FIELDS_NOT_ALLOWED. Use sempre a rota /credentials/certificate.

O que você precisa antes de começar

Item	Detalhe
Certificado A1	Arquivo `.pfx` ou `.p12` (padrão PKCS#12). Certificado A3 (token USB ou cartão físico) não é aceito, porque depende de hardware conectado.
Senha do arquivo	É a senha do próprio arquivo `.pfx`, definida quando o certificado foi emitido ou exportado. Não é a senha do portal do tribunal.
Tamanho	O arquivo precisa ter no máximo 64 KB.
Validade	O certificado precisa estar dentro do prazo de validade. Certificado vencido é recusado no upload.
Sua `api-key`	A mesma chave que você já usa nas demais rotas da Judit.

Se você tem um certificado A3 e precisa usá-lo em consultas automatizadas, será necessário emitir um certificado A1 do mesmo titular. Fale com a sua Autoridade Certificadora (Serasa, Certisign, Soluti, etc.).

Passo 1 — Converter o arquivo `.pfx` para Base64

O JSON de uma requisição HTTP só transporta texto, e um .pfx é um arquivo binário. Por isso, antes de enviar, o arquivo precisa ser convertido para Base64 — que é apenas o mesmo arquivo reescrito como texto.

Base64 não é criptografia nem hash. É só uma forma de representar o arquivo em caracteres de texto. Nada é perdido e nada é embaralhado na conversão.

Escolha o comando de acordo com o seu sistema:

# Gera o Base64 em uma única linha e copia para a área de transferência
base64 -i ./certificado.pfx | tr -d '\n' | pbcopy

# A flag -w 0 evita quebras de linha
base64 -w 0 ./certificado.pfx > certificado.base64.txt

# Gera o Base64 em uma única linha e salva em um arquivo .txt
[Convert]::ToBase64String([IO.File]::ReadAllBytes("C:\caminho\certificado.pfx")) | Set-Content certificado.base64.txt

const fs = require("fs");

const fileBase64 = fs.readFileSync("./certificado.pfx").toString("base64");
console.log(fileBase64);

import base64

with open("certificado.pfx", "rb") as f:
    file_base64 = base64.b64encode(f.read()).decode()

print(file_base64)

A string Base64 precisa estar em uma única linha, sem quebras. Se você usar base64 arquivo.pfx sem tr -d '\n' (macOS) ou sem -w 0 (Linux), o resultado sai quebrado em várias linhas e a API responderá PFX_MALFORMED.

Como saber se deu certo: o texto gerado é enorme (milhares de caracteres — isso é normal) e normalmente começa com MII. Se o que você copiou for algo curto como C:\certificados\meu.pfx ou ./certificado.pfx, você copiou o caminho do arquivo, e não o conteúdo dele.

Passo 2 — Enviar o certificado para o Cofre

curl --location 'https://crawler.prod.judit.io/credentials/certificate' \
--header 'api-key: <api-key>' \
--header 'Content-Type: application/json' \
--data '{
  "customer_key": "teste",
  "system_name": "ESAJ - TJSP - 1º grau",
  "file_base64": "<conteudo-do-pfx-em-base64>",
  "password": "123456"
}'

A autenticação é feita pelo header api-key, exatamente como nas outras rotas da Judit. Não use Authorization: Bearer — essa rota não usa token Bearer.

Campos do corpo da requisição

Campo	Tipo	Obrigatório	Descrição
`file_base64`	string	Sim	Conteúdo do arquivo `.pfx` / `.p12` convertido para Base64, em uma única linha (o resultado do Passo 1).
`password`	string	Sim	Senha do arquivo `.pfx`. Repetindo: é a senha do certificado, não a do tribunal.
`system_name`	string	Recomendado	Sistema e tribunal em que o certificado será usado, exatamente como aparece na lista de sistemas do Cofre — por exemplo `ESAJ - TJSP - 1º grau`. Use `""` para cadastrar o certificado como credencial coringa*, válida para qualquer tribunal que não tenha credencial específica.
`customer_key`	string	Recomendado	Identificador que você define para essa credencial (por advogado, cliente ou escritório). É essa mesma chave que você informará na consulta. Se não for enviada, é usado o valor padrão `"*"`.
`custom_data`	objeto	Não	Só é necessário quando o tribunal também exige autenticação em dois fatores. Veja o Passo 5.

A customer_key é apenas um rótulo de referência escolhido por você. Ela não tem relação com o tribunal e não é uma senha.

Passo a passo no Postman

Método e URL

Selecione POST e informe a URL https://crawler.prod.judit.io/credentials/certificate.

Headers

Na aba Headers, adicione duas linhas:

Key	Value
`api-key`	sua chave da Judit
`Content-Type`	`application/json`

Body

Na aba Body, selecione raw e, no seletor à direita, escolha JSON. Cole o JSON com os quatro campos e substitua file_base64 pelo texto gerado no Passo 1.

Não use form-data nem o tipo File do Postman para anexar o .pfx. Esta rota recebe apenas JSON, com o arquivo já convertido para Base64.

Enviar

Clique em Send. A resposta esperada é um 200 com a mensagem CERTIFICATE_CREATED.

Passo 3 — Conferir a resposta

{
  "message": "CERTIFICATE_CREATED",
  "customer_key": "teste",
  "subject_cn": "NOME DO TITULAR:12345678909",
  "not_after": "2027-01-01T00:00:00.000Z",
  "uploaded_at": "2026-07-31T17:00:00.000Z"
}

Campo	Descrição
`message`	`CERTIFICATE_CREATED` no primeiro envio; `CERTIFICATE_UPDATED` quando você substitui um certificado já cadastrado do mesmo titular.
`customer_key`	Chave da credencial que acabou de ser criada ou atualizada.
`subject_cn`	Titular do certificado (nome e CPF/CNPJ), lido do próprio arquivo. Use para confirmar que enviou o certificado certo.
`not_after`	Data de validade do certificado, em ISO 8601. Anote para renovar antes de vencer.
`uploaded_at`	Data e hora do upload, em ISO 8601.

O certificado é validado no momento do upload (senha, validade e tamanho) e armazenado criptografado. A resposta nunca devolve o arquivo nem a senha — depois de cadastrado, o certificado não pode ser lido de volta.

Passo 4 — Usar o certificado na consulta

O uso é igual ao de qualquer outra credencial do Cofre: basta informar a mesma customer_key em search.search_params.credential.

curl --location 'https://requests.prod.judit.io/requests/' \
--header 'Content-Type: application/json' \
--header 'api-key: <api-key>' \
--data '{
  "search": {
    "search_type": "lawsuit_cnj",
    "search_key": "0000000-00.0000.0.00.0000",
    "search_params": {
      "credential": {
        "customer_key": "teste"
      }
    }
  }
}'

Se você cadastrou o certificado com a customer_key padrão "*", não é necessário informar credential na consulta — ele será usado automaticamente como credencial coringa.

Passo 5 (opcional) — Certificado + código 2FA

Alguns tribunais exigem duas coisas ao mesmo tempo: o certificado digital e o segredo 2FA — enviado no campo secret, e chamado no portal do tribunal de chave secreta, chave manual ou chave de configuração do autenticador. Tudo é feito em uma única requisição: basta acrescentar o objeto custom_data, com a chave secret dentro, ao mesmo payload do certificado.

curl --location 'https://crawler.prod.judit.io/credentials/certificate' \
--header 'api-key: <api-key>' \
--header 'Content-Type: application/json' \
--data '{
  "customer_key": "teste",
  "system_name": "ESAJ - TJSP - 1º grau",
  "file_base64": "<conteudo-do-pfx-em-base64>",
  "password": "123456",
  "custom_data": {
    "secret": "JBSWY3DPEHPK3PXP"
  }
}'

Campo	Tipo	Obrigatório	Descrição
`custom_data`	objeto	Não	Objeto com dados extras da credencial. Envie apenas quando o tribunal exigir 2FA.
`custom_data.secret`	string	Não	Segredo 2FA da credencial — a chave fixa de configuração do aplicativo autenticador.

O secret é a chave fixa de configuração do autenticador (algo como JBSWY3DPEHPK3PXP) — nunca o código temporário de 6 dígitos, que muda a cada poucos segundos. Cadastrar o código de 6 dígitos faz a credencial parar de funcionar em minutos.

Não sabe onde encontrar essa chave? Ela aparece na configuração do 2FA no portal do tribunal, atrás de opções como “Não consigo ler o QR Code”, “Inserir chave manualmente”, “Exibir chave secreta” ou “Setup key”. O passo a passo completo está em Como obter o segredo 2FA para cadastro no Cofre.

Se a credencial já tinha um secret cadastrado anteriormente, o upload do certificado não apaga esse segredo. Você pode enviar custom_data de novo para atualizá-lo, ou omitir o campo para manter o que já está gravado.

Trocar, renovar ou remover o certificado

Renovar ou trocar: repita o mesmo upload com a mesma customer_key e o system_name. A credencial é atualizada, o certificado anterior é descartado e a resposta vem com CERTIFICATE_UPDATED.
Titular diferente: se o novo certificado pertencer a outro CPF/CNPJ, a API retorna CERTIFICATE_HOLDER_MISMATCH (409). Remova a credencial antes de cadastrar o certificado do novo titular.
Consultar: use GET https://crawler.prod.judit.io/credentials?customer_key=teste com o header api-key. Uma credencial cadastrada com system_name: "*" aparece na lista com name: "*".
Remover: use DELETE https://crawler.prod.judit.io/credentials enviando system_name e customer_key. O certificado armazenado é apagado junto com a credencial. Se ela não existir, a resposta é 404 (CREDENTIAL_NOT_FOUND).

Erros e como resolver

Código	HTTP	O que aconteceu	Como resolver
`PFX_MALFORMED`	400	O Base64 está inválido ou o arquivo `.pfx` está corrompido.	Refaça o Passo 1 garantindo uma única linha, sem quebras e sem espaços. Confirme que enviou o conteúdo do arquivo, não o caminho dele.
`PFX_PASSWORD_INVALID`	400	A senha informada não abre o arquivo.	Use a senha do arquivo `.pfx`, não a senha do portal do tribunal. Teste abrir o certificado localmente com essa senha.
`PFX_NO_PRIVATE_KEY`	400	O arquivo não contém a chave privada.	Exporte o certificado novamente marcando a opção de exportar a chave privada.
`PFX_NO_CERTIFICATE`	400	O arquivo não contém certificado.	Verifique se o arquivo exportado é realmente um `.pfx` / `.p12` completo.
`PFX_EXPIRED`	400	O certificado está vencido.	Emita ou renove o certificado junto à Autoridade Certificadora.
`PFX_NOT_YET_VALID`	400	O certificado ainda não entrou em vigor.	Aguarde a data de início da validade.
`PFX_TOO_LARGE`	400	O arquivo tem mais de 64 KB.	Exporte apenas o certificado do titular, sem cadeias ou certificados extras desnecessários.
`CERTIFICATE_HOLDER_MISMATCH`	409	Já existe um certificado cadastrado nessa credencial e ele pertence a outro titular.	Remova a credencial e cadastre novamente com o novo titular.
`CREDENTIAL_TYPE_CONFLICT`	409	Já existe uma credencial de usuário/senha para essa combinação de `customer_key` e sistema.	Use outra `customer_key` para o certificado ou remova a credencial de usuário/senha antes.
`CERTIFICATE_FIELDS_NOT_ALLOWED`	400	Você tentou enviar campos de certificado na rota `POST /credentials`.	Envie o certificado pela rota `POST /credentials/certificate`.

Erros mais comuns na prática

Enviei o caminho do arquivo em vez do conteúdo

"file_base64": "C:\\certificados\\meu.pfx" está errado. O campo espera o texto Base64 gerado no Passo 1, com milhares de caracteres — e não o local do arquivo no seu computador.

O Base64 saiu quebrado em várias linhas

Acontece quando o comando é executado sem tr -d '\n' (macOS) ou sem -w 0 (Linux). Refaça a conversão usando exatamente os comandos do Passo 1.

Usei a senha do tribunal no campo password

O campo password é a senha do arquivo .pfx, criada na emissão ou exportação do certificado. A senha do portal do tribunal não abre o arquivo e gera PFX_PASSWORD_INVALID.

Usei Authorization: Bearer e recebi erro de autenticação

Esta rota autentica pelo header api-key. Remova o header Authorization e envie api-key: sua-chave.

Tentei anexar o .pfx como arquivo no Postman

A rota aceita apenas Content-Type: application/json com o arquivo já convertido para Base64. Não use form-data, binary nem o seletor de arquivos do Postman.

Meu certificado é A3 (token ou cartão)

Certificados A3 exigem o dispositivo físico conectado no momento do login e, por isso, não podem ser cadastrados no Cofre. É necessário um certificado A1 (arquivo .pfx / .p12) do mesmo titular.

Cadastrei o certificado mas a consulta continua sem trazer o processo sigiloso

O certificado apenas autentica o titular. O acesso ao processo depende das permissões daquele titular dentro do tribunal. Se o advogado não estiver habilitado no processo, o retorno continuará limitado aos dados públicos.

Rota de verificação de credenciais cadastradas

Para verificar se uma credencial está cadastrada, envie uma solicitação GET para o endpoint crawler.production.judit.io/credentials, incluindo o parâmetro customer_key correspondente à credencial que deseja consultar. A resposta retornará todas as credenciais disponíveis no cofre associadas à customer_key consultada. O campo credential_status indicará o status de cada credencial:

active: Credencial cadastrada e ativa.
not exists: Credencial não encontrada no sistema.

Segue um exemplo de solicitação GET para verificar a existência de uma credencial:

curl --location 'https://crawler.production.judit.io/credentials?customer_key=teste_01' \
--header 'api-key: <API-KEY>'

Segue um exemplo de resposta para a solicitação GET realizada:

{
    "systems": [
        {
            "name": "*",
            "customer_key": "",
            "credential_status": "not exists"
        },
        {
            "name": "ESAJ - TJAM - 1º grau",
            "customer_key": "teste_01",
            "credential_status": "active"
        },
        {
            "name": "PROJUDI TJGO - 1º grau",
            "customer_key": "teste_01",
            "credential_status": "active"
        }
    ]
}

Como utilizar o Cofre de Credenciais na requisição

O Cofre de Credenciais permite vincular uma consulta a uma credencial previamente cadastrada para o cliente.
Para isso, informe a chave da credencial no campo customer_key, dentro de search.search_params.credential. Essa chave identifica qual credencial deve ser utilizada na execução da consulta.

O valor de customer_key deve corresponder a uma chave já cadastrada no Cofre de Credenciais. Caso a chave informada não exista ou esteja inválida, a consulta poderá falhar ou não utilizar a credencial esperada.

Exemplo de requisição

curl --location 'https://requests.prod.judit.io/requests/' \
--header 'Content-Type: application/json' \
--header 'api-key: <api-key>' \
--data '{
  "search": {
    "search_type": "lawsuit_cnj",
    "search_key": "0000000-00.0000.0.00.0000",
    "search_params": {
      "credential": {
        "customer_key": "CUSTOMER-KEY"
      }
    }
  }
}'

Rota para deletar uma chave no cofre de Credenciais

Para deletar um sistema no cofre de credenciais, você deve realizar uma solicitação DELETE para a rota crawler.production.judit.io/credentials.

Payload da Solicitação

A solicitação DELETE deve incluir um payload com a seguinte propriedade:

system_name: A sigla do tribunal e sistema que será cadastrado a nova credencial.
customer_key: Identificador personalizado adicionado no momento do cadastro da credencial.

Exemplo de payload para deletar credencial:

{
	"system_name": "PROJUDI TJGO - 1º grau",
    "customer_key":"teste_01"
}

Caso a solicitação seja bem sucedida a resposta será um objeto vazio.

A atualização das credenciais nos tribunais é de inteira responsabilidade do usuário. Portanto, cabe ao usuário realizar o cadastro da credencial no tribunal correspondente e acompanhar a validade e a situação da mesma para garantir que ela não seja suspensa ou invalidada.

​Quando usar

Acesso a processos sob segredo

Multi-tenant para escritórios

Conformidade LGPD

Credencial coringa

Certificado digital A1

​Antes de cadastrar no Cofre: cadastro no tribunal

​Fluxo de cadastro e uso

​Permissões da credencial no tribunal

​Autenticação em dois fatores

​Como obter o segredo 2FA para cadastro no Cofre

​Diferença entre segredo 2FA e código temporário

​Como identificar o segredo 2FA

​Fluxo recomendado para cadastro com 2FA

​O que cadastrar no Cofre

​Caso o 2FA já esteja configurado

​Boas práticas para cadastro de credenciais

​Como selecionar a credencial no payload da requisição

​Exemplo de requisição

​Rota para cadastrar suas chaves no cofre de credenciais

​Payload da Solicitação

​Cadastro de credencial com certificado digital (A1)

​O que você precisa antes de começar

​Passo 1 — Converter o arquivo .pfx para Base64

​Passo 2 — Enviar o certificado para o Cofre

​Campos do corpo da requisição

​Passo a passo no Postman

​Passo 3 — Conferir a resposta

​Passo 4 — Usar o certificado na consulta

​Passo 5 (opcional) — Certificado + código 2FA

​Trocar, renovar ou remover o certificado

​Erros e como resolver

​Erros mais comuns na prática

​Rota de verificação de credenciais cadastradas

​Como utilizar o Cofre de Credenciais na requisição

​Exemplo de requisição

​Rota para deletar uma chave no cofre de Credenciais

​Payload da Solicitação

Quando usar

Antes de cadastrar no Cofre: cadastro no tribunal

Fluxo de cadastro e uso

Permissões da credencial no tribunal

Autenticação em dois fatores

Como obter o segredo 2FA para cadastro no Cofre

Diferença entre segredo 2FA e código temporário

Como identificar o segredo 2FA

Fluxo recomendado para cadastro com 2FA

O que cadastrar no Cofre

Caso o 2FA já esteja configurado

Boas práticas para cadastro de credenciais

Como selecionar a credencial no payload da requisição

Exemplo de requisição

Rota para cadastrar suas chaves no cofre de credenciais

Payload da Solicitação

Cadastro de credencial com certificado digital (A1)

O que você precisa antes de começar

Passo 1 — Converter o arquivo `.pfx` para Base64

Passo 2 — Enviar o certificado para o Cofre

Campos do corpo da requisição

Passo a passo no Postman

Passo 3 — Conferir a resposta

Passo 4 — Usar o certificado na consulta

Passo 5 (opcional) — Certificado + código 2FA

Trocar, renovar ou remover o certificado

Erros e como resolver

Erros mais comuns na prática

Rota de verificação de credenciais cadastradas

Como utilizar o Cofre de Credenciais na requisição

Exemplo de requisição

Rota para deletar uma chave no cofre de Credenciais

Payload da Solicitação