estabilidade

O que muda na API, quando muda e com quanto aviso.

Quem integra por código precisa saber o que pode mudar debaixo dos pés. Esta página tem as duas respostas: a política que rege a superfície /v1 e o histórico do que já mudou.

Política de versionamento

Aditivo entra quando estiver pronto
Campo novo na resposta, rota nova, valor novo num enum de saída e header novo não são quebra e entram sem aviso prévio. Escreva o seu cliente para ignorar o que não conhece.
Quebra não entra em /v1
Remover ou renomear campo, estreitar tipo, endurecer validação de entrada ou trocar o significado de um valor exige caminho novo — nunca uma edição no lugar.
Desligar exige 180 dias de aviso
Uma rota só sai depois de anunciada como depreciada e de cumprir o prazo mínimo, contado do anúncio. O prazo está no contrato, não na boa vontade.
Como o aviso chega até você

O anúncio não depende de você ler esta página. Enquanto existir, uma rota depreciada responde com os headers padrão — e o seu cliente HTTP consegue reagir a eles sozinho:

  • Deprecation (RFC 9745) — a data do anúncio.
  • Sunset (RFC 8594) — a data a partir da qual a rota pode deixar de responder.
  • Link — para esta política e, quando existe substituta, para o caminho que assume.

A lista completa também é legível por máquina em GET /, no campo stability.deprecations.

Rotas depreciadas hoje

Nenhuma. Toda rota publicada em /v1 segue em vigor, sem data de desligamento.

Histórico de mudanças

O que passou a existir ou a funcionar diferente para quem integra: rota, campo, header, código de erro, custo em créditos e regra de entrega.

outubro de 2026

  1. Mudou

    A busca de jurisprudência sem recorte pede recorte a partir de 2.000 teores

    POST /v1/publications/text-searches e a tool pesquisar_jurisprudencia, quando o pedido não traz tribunal, período, atribuição, só estruturado nem só colegiado, recusam com QUERY_TOO_BROAD (422) o termo que casa 2.000 teores distintos ou mais, com details.matchedAtLeast em 2000. A recusa sai antes da ordenação e não cobra créditos, e o mesmo termo com qualquer recorte segue para a ordenação. Abaixo disso a busca sem recorte responde como antes, e totalIndexed e o formato da resposta não mudam.

    POST /v1/publications/text-searchespesquisar_jurisprudenciaPOST /mcp
  2. Mudou

    O status público compara cada capacidade com o normal da fonte

    GET /status passa a medir cada capacidade também na última semana da própria fonte. Lentidão, recusa parcial ou índice parado presentes em metade da semana ou mais são o normal da fonte: a capacidade fica OPERATIONAL e o detail diz a condição. Ela volta a DEGRADED quando a condição é nova ou piora muito além do habitual, e OUTAGE não muda. Entre uma rodada de consultas e a seguinte, vale a medição mais recente do último dia, em vez de NO_SIGNAL. O formato e os valores possíveis da resposta não mudaram, então nenhuma adaptação é necessária.

    GET /status
  3. Novo

    A manutenção declarada pela fonte oficial tem código e estado próprios

    Quando a fonte oficial declara manutenção, a consulta que depende dela recebe SOURCE_MAINTENANCE (503, retentável, com Retry-After), sem cobrança, e a mensagem diz desde quando, no horário de Brasília; no canal agentic, a recusa diz também quanto esperar antes de repetir. A /status mostra a capacidade afetada como MAINTENANCE, com a frase da recusa. Os monitores ganham sourceMaintenance, com o começo e a frase da manutenção da fonte de que cada um depende, e listar_monitores traz a frase em fonteEmManutencao. As vigílias não contam falha nem emitem MONITOR_SYNC_FAILED durante a manutenção: retomam sozinhas quando a fonte volta e cobrem o período que ficou para trás. Na lista de colheita, a fatia que encontrou a manutenção diz isso em lastError e volta à fila sozinha. O SDK 1.31.0 traz o código em LEXNODE_ERROR_CODES e, com a repetição automática ligada, deixa de repetir antes do prazo a recusa cujo Retry-After passa de maxDelayMs: lança a recusa na hora, e retryAfterSeconds diz quando vale tentar de novo. Isso vale para toda recusa com espera maior que maxDelayMs, não só para a da manutenção. Cliente que valida em modo estrito o status de GET /status — o de cada componente e o agregado — precisa aceitar o valor novo MAINTENANCE. Nas rotas de processo, o tribunal fora do catálogo é recusado antes de qualquer consulta à fonte, com TRIBUNAL_NOT_SUPPORTED (400, terminal), e a recusa pede a sigla.

    GET /statusGET /v1/publications/v1/processesGET /v1/monitorsGET /v1/monitors/{monitorId}GET /v1/publications/corpus/harvest-requestsPOST /mcpbuscar_publicacoesconferir_carteiralistar_monitoresRetry-After
  4. Novo

    O SDK acompanha a recuperação de uma consulta processual

    O SDK 1.30.0 oferece readProcessWithRecovery para abrir uma consulta, aceitar explicitamente uma cópia antiga e acompanhar o resultado dentro do orçamento escolhido. O retorno distingue processo disponível, consulta pendente, falha, cancelamento e expiração, preservando a data da fonte. Encerrar o acompanhamento mantém o mesmo recibo para uma leitura posterior; não abre outra consulta. O helper usa as rotas existentes e mantém seus preços e controles de acesso.

    POST /v1/processes/lookupsGET /v1/processes/lookups/{lookupId}
  5. Novo

    A busca de jurisprudência entrega o ranking quando a cobertura não cabe no prazo

    POST /v1/publications/text-searches apura a cobertura do recorte — o retrato, em coverage, do que estava indexado — com prazo próprio, ao lado da ordenação. Quando a cobertura não cabe nesse prazo, a busca responde com o ranking inteiro, pelo preço de sempre — o que ela entrega é o ranking —, e congela coverage.overallState com o valor novo UNAVAILABLE e byTribunalMonth vazio; a tool pesquisar_jurisprudencia entrega os acertos no mesmo caso. O valor congelado volta igual em GET /v1/publications/text-searches/{searchId} e não muda depois; a cobertura do mesmo recorte sai em GET /v1/publications/corpus/coverage, a 0 crédito, com os mesmos tribunais num só tribunalCodes, separados por vírgula (tribunalCodes=STJ,TJSP), e a mesma janela. A recusa QUERY_TOO_BROAD (422) da ordenação vale também quando a cobertura não coube no prazo, e DATABASE_TIMEOUT (503) segue possível com o banco sobrecarregado, pedindo para repetir a mesma chamada. O estado de cada grupo, o de cada matéria e o da rota de cobertura não usam o valor novo. Contrato 1.29.0.

    POST /v1/publications/text-searchesGET /v1/publications/text-searches/{searchId}pesquisar_jurisprudenciaPOST /mcp
  6. Mudou

    O status público mostra a lentidão que se sustenta e o índice parado

    GET /status passa a marcar como DEGRADED a capacidade cuja fonte oficial fica lenta de forma sustentada na janela medida — metade ou mais das respostas além do limite de lentidão, ou parte das consultas sem terminar no tempo —, com texto próprio. A lentidão isolada segue OPERATIONAL, e a janela em que nenhuma consulta termina segue OUTAGE. A consulta processual também fica DEGRADED quando a fonte oficial deixa de atualizar o índice de processos por mais de dois dias úteis: as consultas terminam, mas movimentos novos podem não aparecer. O formato e os valores possíveis da resposta não mudaram, então nenhuma adaptação é necessária.

    GET /status

setembro de 2026

  1. Novo

    Todos os graus de um processo, o aviso de grau novo e o recorte por grau

    GET /v1/processes/{processNumber} e GET /v1/processes/{processNumber}/snapshot listam em data.instances todos os documentos que o motor guarda do número — em geral um por instância (1º grau, 2º grau, turma recursal…), às vezes dois do mesmo grau —, a principal primeiro, cada um com primary, origin (SOURCE quando veio da fonte nesta resposta, LAKE quando saiu do acervo), fetchedAt e absentSince. No retrato, cada instância traz os movimentos da última captura dela, sem o payload bruto da fonte, e movements nulo quando eles nunca foram capturados; a ficha retida pelo controle de confidencialidade sai sem a lista. O item de POST /v1/processes/snapshot-batch lista as instâncias só com o cabeçalho, e a busca por número completo servida do acervo devolve um item por documento que a fonte ainda traz do número, a principal primeiro; quando eles não cabem em limit, a busca vai à fonte, que pagina. GET /v1/processes/{processNumber}/movements aceita degree e diz em degrees o grau que trouxe cada movimento. O webhook PROCESS_INSTANCE_DISCOVERED avisa quem assina o processo quando outro grau aparece na fonte, com o grau, o órgão julgador e quantos movimentos ele trouxe; PROCESS_MOVEMENT_CREATED ganha degree, instanceSourceId e instances, a contagem de movimentos novos por grau, e o MONITOR_SYNC_SUCCEEDED da vigília de processo ganha instances e instancesDiscovered quando o dono do monitor pode ler o número inteiro. No processo não compartilhável os avisos saem sem grau. Nas tools, consultar_processo traz cada instância, a que se moveu por último primeiro, e segue por grau e pagina com os movimentos que o motor guardou, por 1 crédito e sem ir à fonte, para quem já leu o processo ou o acompanha; ler_processo diz os outros graus do número, listar_monitores lista os graus da vigília de processo e novidades aponta o grau no aviso de grau novo. Contrato 1.27.0.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotGET /v1/processes/{processNumber}/movementsPOST /v1/processes/snapshot-batchPOST /v1/processes/searchPROCESS_INSTANCE_DISCOVEREDPROCESS_MOVEMENT_CREATEDMONITOR_SYNC_SUCCEEDEDconsultar_processoler_processolistar_monitoresnovidadesPOST /mcp
  2. Mudou

    O grau novo de um processo chega num aviso só, e o topo da leitura não troca

    Quando outro grau de um processo que já tinha movimentos aparece na fonte, o histórico dele entra no acervo e chega a quem assina o processo num PROCESS_INSTANCE_DISCOVERED, e não mais movimento a movimento em PROCESS_MOVEMENT_CREATED; os movimentos dele datados depois da primeira captura do número seguem saindo como novos. O aviso de grau novo sai só de uma resposta completa da fonte pelo número, e o documento que apenas substitui outro do mesmo grau não é anunciado. PROCESS_MOVEMENT_CREATED segue um por assinante e por captura, agora descrito pelo movimento novo mais recente, que dá a chave de deduplicação; no processo restrito, ele e o aviso de grau novo vão só a quem o controle de confidencialidade serviria ou entregaria retido. O topo da ficha e do retrato é sempre a instância principal do número — escolhida na primeira captura dele, e que só muda quando uma resposta completa da fonte deixa de trazê-la —, e não o primeiro documento da resposta; os outros estão em data.instances. A resposta parcial da fonte que traz o processo passa a ser servida também quando traz outro grau do que o acervo guardava: a principal sai do acervo, marcada LAKE, e o retrato responde 502 UPSTREAM_UNAVAILABLE quando o acervo não guarda os movimentos dela. A busca assíncrona devolve, em cada item, o documento que casou com o filtro; o número que o controle de confidencialidade retém conta uma vez no total do job e do SEARCH_JOB_COMPLETED, quantos documentos dele a busca tenha achado, e processNumbers traz cada número uma vez. Com um documento em segredo de justiça, o número inteiro sai restrito, em todos os graus. meta.otherInstances mantém os valores.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotGET /v1/search-jobs/{jobId}SEARCH_JOB_COMPLETEDPROCESS_MOVEMENT_CREATEDPROCESS_INSTANCE_DISCOVEREDconsultar_processo
Ver anteriores
  1. Novo

    No agente, a leitura de processo segue em segundo plano e tem tool própria

    ler_processo e consultar_processo ganham continuarEmSegundoPlano, ligado por padrão: quando a fonte processual não entrega dentro da espera e o acervo não tem cópia a servir, a tool responde sem erro e sem cobrar, com o id da consulta que segue tentando sozinha por até 6 h, o que fica reservado e até quando a mesma chamada devolve a mesma consulta. A cópia guardada mais velha que o frescor do plano, servida no lugar da fonte, também passa a ser atualizada em segundo plano: a cópia cobra 1 crédito na hora e a versão atual, o resto do preço da leitura, só se vier. A tool nova acompanhar_consulta diz como está cada consulta e traz o processo entregue sem nova cobrança — o retrato por instância, como consultar_processo o mostra, com as páginas seguintes de cada grau por grau e pagina, sem ir à fonte; sem id, lista as abertas da chave. novidades avisa o fim de cada consulta. Com continuarEmSegundoPlano: false, as duas tools respondem como antes. Quando a chave já tem 5 consultas abertas, ou a conta 20, a recusa da fonte diz isso.

    ler_processoconsultar_processoacompanhar_consultanovidades
  2. Novo

    Leitura de processo que segue em segundo plano quando a fonte não entrega

    POST /v1/processes/lookups faz a leitura da ficha (view: "PROCESS") ou do retrato com os movimentos (view: "SNAPSHOT") dentro de waitSeconds. Quando ela cabe na espera, responde 200 com o processo, pelo mesmo preço e com o mesmo meta da leitura direta, com as instâncias do número em instances como ela as traz. Quando a fonte processual falha — não responde a tempo, fica indisponível ou pede para esperar por volume —, responde 202 com uma consulta que segue tentando sozinha por até 6 h, com Location e Retry-After, sem cobrar na hora: o preço da leitura fica retido e só é cobrado se o processo vier. GET /v1/processes/lookups/{lookupId} lê a consulta sem custo e traz o processo por 24 h depois da entrega; GET /v1/processes/lookups lista as consultas e POST /v1/processes/lookups/{lookupId}/cancel cancela a aberta, devolvendo a retenção. O fim sai no evento novo PROCESS_LOOKUP_COMPLETED, que aponta a consulta sem trazer o processo. A mesma leitura pedida de novo devolve a mesma consulta; com staleOnFailure: true, o 202 traz a cópia guardada em stale, por 1 crédito, e a entrega cobra só o resto do preço. A leitura direta do mesmo processo que dá certo fecha a consulta aberta sem cobrar. Código de erro novo: PROCESS_LOOKUP_NOT_FOUND, para consulta de outra conta ou escritório. /v1/search-jobs segue listando, lendo e cancelando só a busca assíncrona de processos. Contrato 1.28.0.

    POST /v1/processes/lookupsGET /v1/processes/lookupsGET /v1/processes/lookups/{lookupId}POST /v1/processes/lookups/{lookupId}/cancelPROCESS_LOOKUP_COMPLETEDLocationRetry-After
  3. Novo

    Leitura de processo socorrida pelo acervo, com a data

    GET /v1/processes/{processNumber}, GET /v1/processes/{processNumber}/snapshot e as tools ler_processo e consultar_processo: quando a fonte processual falha — não responde dentro da espera, fica indisponível, responde com parte do índice sem poder servir o processo ou pede para esperar por volume — e o acervo guarda uma cópia do processo, a leitura serve essa cópia com a data em que ela foi buscada. Na API, meta.lakeRescue traz a causa — e, na recusa por volume, retryAfterSeconds, repetido no header Retry-After — e meta.sourceFetchedAt traz a data, que passa a acompanhar toda resposta das duas rotas, menos a ficha que o controle de confidencialidade entrega retida, sem o teor. A cópia de qualquer idade vem com staleOnFailure=true; sem ele, só a de até 24 h. Nas tools, a cópia de qualquer idade vem sempre, com uma linha antes do processo que diz a data, o grau e o que a fonte fez. O retrato socorrido traz os movimentos da última captura guardada e sourcePayload nulo; a ficha socorrida relê na hora o resumo das publicações. A resposta da fonte sem o processo segue 404 PROCESS_NOT_FOUND. Além de 24 h, só recebe a cópia quem já tem interesse registrado no processo, de uma leitura anterior ou de uma assinatura ativa; os demais recebem a falha da fonte. No lote, o item socorrido traz lakeRescue com a causa e a data. Contrato 1.26.0.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotPOST /v1/processes/snapshot-batchRetry-Afterler_processoconsultar_processoPOST /mcp
  4. Mudou

    O retrato socorrido pelo acervo cobra 1 crédito, e a ficha também é socorrida

    O retrato servido pelo acervo porque a fonte falhou — GET /v1/processes/{processNumber}/snapshot, a tool consultar_processo e o item de POST /v1/processes/snapshot-batch — cobra 1 crédito em vez de 8; o retrato servido pela fonte segue 8, e o saldo continua precisando cobrir 8 para a chamada começar. A ficha, que não tinha socorro, passa a servir a cópia de até 24 h quando a fonte falha, por 1 crédito, como a ficha servida do acervo. A recusa de consultar_processo por tempo esgotado ou índice parcial aponta ler_processo como saída, sem prometer a cópia.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotPOST /v1/processes/snapshot-batchler_processoconsultar_processo
  5. Mudou

    A leitura de um processo insiste no índice parcial e diz as outras instâncias

    GET /v1/processes/{processNumber}, GET /v1/processes/{processNumber}/snapshot e as tools ler_processo e consultar_processo: quando a fonte processual responde sem o processo porque partes do índice ficaram fora, o motor consulta de novo, até duas vezes, com uma pausa curta, enquanto a espera escolhida couber; a resposta inteira sem o processo segue 404 PROCESS_NOT_FOUND, e a parcial que ainda não o traz segue 502 UPSTREAM_UNAVAILABLE. Quando a resposta traz mais de um documento do número — em geral de instâncias diferentes —, o motor continua servindo e guardando o mesmo, e meta.otherInstances lista os outros que vieram, com grau, data de atualização na fonte e órgão julgador; nas tools, uma linha antes do processo diz qual grau foi servido e que outros documentos a fonte tem. A lista não sai para processo restrito. As recusas das duas tools dizem que a chamada não consumiu créditos; à chave que lê monitores, citam a vigília de processo que a conta já tem — com a última verificação e a próxima — em vez de sugerir criar outra; o tempo esgotado sugere uma repetição com espera maior sempre que foi a espera escolhida que cortou a última ida à fonte; e o 404 lembra que processo sob segredo de justiça pode não estar na fonte pública. listar_monitores ganha ultimaVerificacaoEm, proximaVerificacaoEm e agendaDaVerificacao. Contrato 1.25.0; códigos e status de erro não mudam.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotler_processoconsultar_processolistar_monitoresPOST /mcp
  6. Mudou

    A leitura de um processo espera mais pela fonte lenta, e quem chama escolhe quanto

    GET /v1/processes/{processNumber} e GET /v1/processes/{processNumber}/snapshot aceitam waitSeconds, de 10 a 180 (padrão 20), e as tools ler_processo e consultar_processo aceitam maxWaitSeconds, na mesma faixa (padrão 120): é o teto da consulta à fonte processual, cada ida a ela espera até 60 s, e a segunda ida só sai depois de uma recusa por volume ou de um erro da fonte, nunca depois de tempo esgotado. Depois dela, a ficha ainda espera até 10 s pelo resumo das publicações do processo, então o tempo limite do cliente precisa cobrir a espera, esses segundos e a rede. Valor fora da faixa é recusado com os limites na mensagem: 400 VALIDATION_ERROR na API, argumento inválido nas tools. Quando a fonte responde com parte do índice e o processo está na parte que respondeu, ele é servido e a resposta vem marcada — meta.partialIndex na API, uma linha antes do processo nas tools —, porque outra instância do mesmo número pode não ter vindo. Sem o processo, ou com uma instância diferente da que o acervo já guarda, a resposta parcial continua 502 UPSTREAM_UNAVAILABLE retentável, nunca 404. As recusas das duas tools dizem se foi lentidão da fonte, índice parcial ou processo que não há para a conta, e o que fazer em cada caso. O snapshot em lote e a busca não mudam, e códigos e status de erro também não.

    GET /v1/processes/{processNumber}GET /v1/processes/{processNumber}/snapshotler_processoconsultar_processoPOST /mcp
  7. Mudou

    A busca de jurisprudência ampla volta como recusa acionável, e não como falha temporária

    POST /v1/publications/text-searches e a tool pesquisar_jurisprudencia deixam de responder DATABASE_TIMEOUT (503, temporária) depois de quase 30 s quando o termo casa teor demais no recorte pedido. Com recorte — tribunal, período, atribuição, só estruturado ou só colegiado —, a ordenação começa com o prazo inteiro, e o estouro dela é QUERY_TOO_BROAD (422, terminal), que pede período mais curto ou termo mais específico, também com o banco carregado. Sem recorte, a recusa sai da contagem do que o termo casa, que lê uma amostra de tamanho fixo e não depende do tempo. Por isso o mesmo pedido que antes podia voltar como 503 retentável pode voltar como 422 terminal: repetir custa o mesmo, recortar resolve. DATABASE_TIMEOUT segue possível com o banco sobrecarregado — sem conexão livre a tempo, ou com a contagem ou as leituras que acompanham a ordenação sem terminar no prazo — e segue pedindo para repetir a mesma chamada. totalIndexed e o formato da resposta não mudam.

    POST /v1/publications/text-searchespesquisar_jurisprudenciaPOST /mcp
  8. Mudou

    O canal agentic atende a conta sem assinatura vigente e diz como assinar

    Com a avaliação vencida, o plano cancelado, o pagamento em atraso além da carência ou a conta ainda sem plano, initialize, ping e tools/list do POST /mcp respondem como na conta em dia, e o conector segue conectado. saldo_e_uso responde e traz assinatura, com vigente, codigo, motivo e regularizarEm, o endereço do portal onde se assina; na conta em dia o bloco não aparece. As demais tools recusam em banda (isError), com o código da recusa (ENTITLEMENT_REQUIRED, SUBSCRIPTION_REQUIRED, ENTITLEMENT_EXPIRED ou SUBSCRIPTION_INACTIVE) e o mesmo endereço; assinado o plano, a mesma conexão volta a responder, sem reconectar. Credencial ausente, revogada ou vencida continua recebendo 401 com o desafio em todo método. A superfície /v1 não muda.

    POST /mcpsaldo_e_uso
  9. Mudou

    A consulta viva ao diário segue um ritmo com a fonte e diz quando voltar

    A busca de publicações que consulta o diário na hora (GET /v1/publications e a tool buscar_publicacoes) passa por um ritmo que o motor mantém com a fonte, somando todo o tráfego que sai pelo mesmo endereço. No limite desse ritmo, a resposta é UPSTREAM_RATE_LIMITED (429) com o cabeçalho Retry-After e retryAfterSeconds nos detalhes — o mesmo código e a mesma conduta da recusa por volume da fonte: esperar o prazo e repetir. No canal agentic, o texto da recusa diz qual das duas foi. Quando o motor não consegue contar a vaga, a resposta é DATABASE_UNAVAILABLE (503, retentável). O formato da resposta não muda.

    GET /v1/publicationsbuscar_publicacoesPOST /mcp
  10. Mudou

    O calendário forense traz os feriados forenses de cada ramo

    GET /v1/court-calendar e a tool consultar_calendario_forense passam a devolver à Justiça Federal, aos tribunais superiores e às justiças do Trabalho e Eleitoral a segunda de Carnaval, a Semana Santa de quarta a domingo, 11/8 e 1º/11, e a todo tribunal o Dia da Justiça (8/12). As entradas saem com scope: NATIONAL: quem filtra esse scope por aplicar o próprio calendário nacional confere se o dele traz esses dias. Quando o tribunal transferiu um deles por ato próprio e o motor conhece o ato, o dia vem no dia transferido, com transfer. Para grafia de tribunal que o catálogo não reconhece, as camadas NATIONAL_MOVABLE e NATIONAL_FIXED são declaradas COURT_NOT_RECOGNIZED, porque só os feriados de todo foro vêm na lista. O formato da resposta não muda.

    GET /v1/court-calendarconsultar_calendario_forense
  11. Mudou

    A cobertura do acervo no agente é um retrato recente com data

    cobertura_do_acervo devolve, no resumo, apuradoEm: o instante em que o retrato daquele recorte foi apurado. A mesma pergunta repetida em poucos minutos, com os tribunais em qualquer ordem, pode voltar do retrato já apurado. O motor apura um número limitado de coberturas ao mesmo tempo, somando todas as contas; com o teto ocupado, a chamada volta como falha temporária RATE_LIMITED com o prazo de espera, e esse teto é do motor, não do plano. O banco sem conexão livre a tempo volta como DATABASE_TIMEOUT, também temporária, para repetir a mesma chamada. QUERY_TOO_BROAD fica para o recorte cuja consulta não coube no prazo, que pede janela mais curta ou menos tribunais. A tool segue custando 0 crédito.

    cobertura_do_acervo
  12. Mudou

    Corpus Christi sai no calendário forense pela lei que o institui

    Corpus Christi não é feriado nacional, e GET /v1/court-calendar e a tool consultar_calendario_forense passam a devolvê-lo com scope: STATE onde a lei estadual o institui e com scope: MUNICIPAL na comarca cuja lei municipal o faz dia de guarda — informe municipalityIbgeCode para alcançá-lo. A camada NATIONAL_MOVABLE traz a terça de Carnaval e a Sexta-feira Santa. Quando o motor conhece o calendário da comarca e não tem Corpus Christi catalogado para ela, o detail da camada MUNICIPAL diz isso; o ponto facultativo do tribunal segue na camada de suspensão, que a rota não serve. O formato da resposta não muda.

    GET /v1/court-calendarconsultar_calendario_forense
  13. Mudou

    O canal agentic autentica antes de recusar tool ou método

    No POST /mcp, o tools/call com nome de tool que não existe e o método JSON-RPC que o servidor não atende passam pela credencial antes da recusa. Sem credencial, a resposta é o 401 com WWW-Authenticate, como no initialize e no tools/list. Com ela, a recusa de tool desconhecida (-32602) lista só as tools que aquela credencial pode chamar, e a de método (-32601) segue como era. O desafio WWW-Authenticate passa a trazer scope="agent", o escopo a pedir na autorização. Notificação, batch, JSON-RPC inválido e revisão de protocolo recusada continuam respondendo sem credencial.

    POST /mcpWWW-Authenticate
  14. Novo

    Cada endpoint de webhook recebe uma entrega por vez

    O motor manda a um endpoint uma entrega de cada vez, na ordem da fila dele: a seguinte só sai depois que a anterior foi respondida ou venceu o timeout de 15 segundos. Endpoints diferentes seguem recebendo em paralelo. Uma reentrega ainda pode chegar depois de um evento mais novo, então occurredAt continua sendo a referência de ordem, e o id do evento, a de deduplicação. Formato, assinatura e tentativas não mudam.

    Webhooks
  15. Mudou

    A edição da última semana do diário é colhida antes dos dias pedidos

    A fila de colheita atende primeiro os dias da última semana do diário, até a edição de ontem, e em seguida as fatias pedidas por POST /v1/publications/corpus/harvest-requests, por requestHarvest na busca textual ou pela tool pedir_colheita; a colheita histórica do próprio motor segue atrás das duas. A fatia pedida de um dia dessa semana corre junto com a edição; a de hoje entra na fila dos pedidos e sobe para a da edição quando o dia vira ontem. Um pedido nunca rebaixa uma fatia. No progresso das fatias, priority mostra 20 e 15 nas da última semana; quando o dia sai dela sem ter sido colhido, a fatia pedida volta a 10. Preço, tetos e formato do pedido não mudam.

    POST /v1/publications/corpus/harvest-requestsGET /v1/publications/corpus/harvest-requestsPOST /v1/publications/text-searchespedir_colheita
  16. Novo

    O calendário forense segue o feriado que o tribunal transferiu

    Quando o tribunal transfere um feriado por ato próprio e o motor conhece o ato, GET /v1/court-calendar e a tool consultar_calendario_forense devolvem o feriado no dia que o ato fixa, na mesma camada e com o campo opcional transfer: fromDate é o dia da lei, que deixa de sair na lista para aquele tribunal, e act e url citam o ato e onde ele foi lido. A transferência de feriado municipal vale só na comarca dele. Onde o motor não conhece transferência nenhuma, a resposta é a de sempre, e a declaração de cobertura da camada de suspensão diz isso.

    GET /v1/court-calendarconsultar_calendario_forense
  17. Mudou

    O extrato diz por que uma requisição foi recusada

    Cada evento de recentEvents em GET /v1/usage que não foi servido traz errorCode, o código do erro que recusou a requisição ou o trabalho de fundo, e, num 400 de validação, fieldPaths com os campos recusados em notação de ponto (root é o corpo ou a query inteira). Só o código e o nome do campo: nenhum valor enviado nem mensagem fica guardado. O motivo aparece também nas recusas na porta (cota, escopo, assinatura) e nas varreduras de fundo que já o tinham registrado. No portal, o extrato de uso mostra o motivo e os campos em cada recusa, e a planilha exportada ganha as colunas motivo e campos.

    GET /v1/usagePortal
  18. Novo

    O agente lê a ficha do processo, acha o recurso e vê a cobertura do acervo

    Quatro tools novas no canal MCP, cada uma com o escopo e o preço da rota equivalente. ler_processo devolve a ficha do processo sem os movimentos (GET /v1/processes/{processNumber}): 1 crédito quando o acervo responde, 3 quando a ficha vem da fonte — a leitura barata ao lado de consultar_processo, que traz o andamento. processos_relacionados responde se o processo tem recurso (/related, 1 crédito): o mesmo número em outra instância e os números citados nos movimentos, só entre o que já está no acervo. cobertura_do_acervo resume, para os tribunais nomeados, o volume, o intervalo e os meses em colheita do acervo de pesquisa, a 0 crédito — nos últimos meses por padrão, ou na janela de/ate informada —, e pedir_colheita pede os dias que faltam, cobrando 1 crédito só por fatia nova, dizendo quantas fatias do pedido foram aceitas, quantas já estavam no acervo e qual janela pedir em seguida. Nas tools de processo (ler_processo, consultar_processo, processos_relacionados) e nas duas do acervo, a grafia de tribunal que o catálogo não conhece é recusada com TRIBUNAL_NOT_SUPPORTED antes de qualquer leitura ou cobrança. A chave de teste não enxerga pedir_colheita.

    MCPler_processoprocessos_relacionadoscobertura_do_acervopedir_colheita
  19. Novo

    Permissões de uma chave se ajustam sem trocar o segredo

    No portal, "Editar permissões" muda os escopos de uma chave ativa e mantém o mesmo segredo: a integração segue no ar, sem redistribuir credencial. A requisição seguinte já obedece ao conjunto novo — escopo acrescentado libera a rota na hora, e escopo retirado não tem carência: a chamada que dependia dele passa a responder 403 INSUFFICIENT_SCOPE. Depois de uma rotação, a chave anterior mantém os escopos que tinha enquanto dura a carência dela: o ajuste vale para a chave editada. O catálogo de tools do canal MCP acompanha o conjunto, e a troca entra no extrato de auditoria com as permissões de antes e as de depois. A chave que sustenta uma conexão de agente não se edita: as permissões dela vêm do consentimento, e mudá-las é reconectar.

    PortalPOST /mcp
  20. Mudou

    A tabela de escopos do OpenAPI lista cada escopo com o rótulo do portal

    A seção "Escopos da chave de API" do documento traz todo escopo que uma chave emitida no portal pode carregar, com o rótulo que o portal mostra e o que ele libera — inclusive EVENTS_READ (Ler eventos: GET /v1/events e /v1/events/{eventId}). A linha de USAGE_READ diz que ele ainda abre /v1/events como legado; chave nova pede EVENTS_READ.

    GET /openapi.json
  21. Mudou

    Consultas à fonte pelo conector aparecem no consumo diário

    As consultas à fonte feitas pelo canal MCP passam a ser registradas também quando a consulta de processo usa o acervo após uma falha ou a sonda de um novo monitor de parte falha. Essas tentativas contam no teto diário de consultas à fonte; os créditos seguem a regra de cada operação. O catálogo do conector identifica as ferramentas que podem consultar fontes públicas.

    POST /mcpconsultar_processocriar_monitor_de_parte
  22. Novo

    O receptor lembra o último teste

    POST /v1/webhooks/endpoints/{endpointId}/test continua síncrono e fora da fila, e agora deixa o desfecho no receptor: lastTestAt, lastTestStatus (o HTTP que ele devolveu; nulo sem resposta) e lastTestError (o que impediu o aceite; nulo num 2xx) vêm em GET /v1/webhooks/endpoints e em GET /v1/webhooks/health, ao lado de lastDeliveredAt. O teste não conta como entrega e não mexe na série de recusas nem na suspensão: só a entrega real as move. No portal, o cartão do receptor mostra "Último teste" ao lado de "Última entrega", e o disparo entra no extrato de auditoria da conta.

    POST /v1/webhooks/endpoints/{endpointId}/testGET /v1/webhooks/endpointsGET /v1/webhooks/healthPortal
  23. Novo

    O ciclo inteiro do acesso no extrato de auditoria

    Sair, confirmar o e-mail e redefinir a senha aparecem no extrato de auditoria da conta atribuídos à pessoa, na mesma linha do tempo em que já estão login, chaves e vigílias.

    Portal
  24. Novo

    Busca e vigília por CNPJ, em qualquer grafia

    partyDocument aceita o CNPJ nos 14 dígitos ou pontuado e o normaliza para NN.NNN.NNN/NNNN-NN, a grafia que o teor escreve; vale em GET /v1/publications, na tool buscar_publicacoes, na criação de vigília (POST /v1/monitors com type: "DOCUMENT", a tool criar_monitor_de_documento e o portal) e no filtro da lista de monitores. O eixo casa o documento no teor do ato e por isso acha a empresa citada — mandada citar, garantidora, penhorada — antes de ela figurar como parte; cada item da busca e cada PUBLICATION_CREATED da vigília vem com matchedBy: "document". includeBranches: true busca pela raiz de 8 dígitos e alcança matriz e filiais — opção declarada, nunca padrão, porque muda a contagem. Os três eixos de empresa se completam: nome acha as irmãs, advogado confirma o grupo, documento acha a citação antes da parte. A vigília por documento divide a vaga de diário com as de termo e de nome de parte, e a busca custa o mesmo que a textual. CPF segue recusado com PERSONAL_DOCUMENT_QUERY_NOT_ALLOWED.

    GET /v1/publicationsPOST /v1/monitorsMCPPortalWebhooks
  25. Mudou

    O sinal de vida da vigília nasce desmarcado no formulário

    Ao criar um receptor no portal, MONITOR_SYNC_SUCCEEDED vem desmarcado e a opção diz a cadência: sai a cada varredura, até 96 por dia por monitor, quase sempre sem novidade. Quem o quer marca lendo o que vai receber.

    Portal
  26. Novo

    O que a conta produz e nenhum receptor assina

    Todo evento nasce como registro mesmo sem endpoint que o assine e fica disponível por 180 dias. GET /v1/webhooks/unsubscribed-event-types lista os tipos que a conta produziu nos últimos 30 dias sem nenhum endpoint ativo assinando — contagem, último instante e a classe (DATA é o produto, OPERATIONAL é sinal sobre a operação). A tela de webhooks do portal mostra o mesmo bloco, abre o receptor com o tipo já marcado e deixa dispensar os operacionais; a caixa de avisos diz por que um aviso não foi entregue: sem receptor, receptor que não assina o tipo, entrega ainda na fila ou entrega que esgotou as tentativas — o resumo deliveries de GET /v1/webhooks/events passa a trazer failed e pending ao lado de total e delivered. Assinar o tipo depois mais o reenvio por janela recupera o que já nasceu — nada é assinado nem reenviado sozinho. MONITOR_SYNC_SUCCEEDED nunca entra na lista: sai a cada varredura, até 96 por dia por monitor, e não assiná-lo é a escolha esperada.

    GET /v1/webhooks/unsubscribed-event-typesGET /v1/webhooks/eventsPortalWebhooks
  27. Novo

    Sub-tenants por X-Office-Id, com teto por plano

    Uma plataforma que atende vários clientes finais abre UMA conta e atribui cada chamada ao cliente com o header X-Office-Id; o consumo sai repartido em byOffice, e a leitura recorta pelo sub-tenant. Cada plano diz quantos sub-tenants admite por período: GET /v1/usage passa a devolver subTenantLimit (nulo é sem teto) e subTenantsUsed, os que já receberam requisição no período. Um office novo além do teto é recusado com 403 SUB_TENANT_LIMIT_EXCEEDED, dizendo o teto e o plano que o remove; os já atendidos passam sempre. A tela de uso do portal mostra os mesmos dois números.

    GET /v1/usagePortal
  28. Novo

    O portal diz quando a avaliação terminou

    A conta cuja avaliação terminou sem virar assinatura vê isso escrito com o nome certo no aviso do topo, na página inicial e na tela de cobrança — esta com a data em que o acesso encerrou. O caminho de volta continua o mesmo: escolher um plano.

    Portal
  29. Novo

    A autorização de débito é mostrada antes do pagamento

    Ao assinar um plano — no cadastro ou pelo portal — a frase da autorização de débito aparece na tela antes de o cliente seguir para o cartão: plano, valor, como renova e como cancelar — e, quando há avaliação, a data da primeira cobrança no horário de Brasília. A mesma frase fica registrada com a autorização, ligada à assinatura que ela sustenta.

    Portal
  30. Mudou

    CPF não é chave de consulta nem de vigília

    O motor recusa o documento de pessoa natural como chave em toda porta: text, partyName e lawyerName de GET /v1/publications, query de POST /v1/publications/text-searches e de POST /v1/publications/text-alerts, term e partyName de POST /v1/monitors, e as tools equivalentes do canal agentic. A recusa sai como 400 com o código próprio PERSONAL_DOCUMENT_QUERY_NOT_ALLOWED, para não se confundir com um campo mal digitado. CNPJ continua aceito em todas elas. A vigília já cadastrada com um CPF como alvo é pausada pelo motor, com aviso ao titular, e a linha de consumo passa a guardar o caminho da chamada com o documento mascarado.

    GET /v1/publicationsPOST /v1/publications/text-searchesPOST /v1/publications/text-alertsPOST /v1/monitorsMCP
  31. Mudou

    Datas de cobrança e do portal no horário de Brasília

    A data da primeira cobrança na autorização de débito, os avisos por e-mail e as datas que o portal e o console exibem saem no horário de Brasília, com o fuso nomeado no texto da autorização. Datas de calendário sem hora, como o dia de julgamento, continuam como estão.

    PortalE-mailMCP
  32. Novo

    O catálogo diz até quando cada tribunal foi lido

    GET /v1/tribunals passa a trazer processIndex por tribunal: até quando o índice da fonte está lido no eixo do processo, e quando isso foi medido. A marca já qualificava uma busca — ela é o que separa "não existe" de "ainda não chegou" —, mas só existia dentro da resposta de uma consulta com recorte. Quem publica cobertura, painel ou página de confiança perguntava pelo acervo inteiro e não tinha a quem: sondar noventa tribunais por visita não é resposta. Nulo onde ainda não há medição para aquele tribunal — ausência de marca não é marca de ausência. Campo aditivo, e a rota segue a zero crédito.

    GET /v1/tribunals
  33. Novo

    O receptor diz o alcance que tem

    Todo endpoint de webhook passa a trazer reach: se ele é da CONTA inteira ou de um projeto, quantos projetos alcança hoje e se o que um projeto futuro produzir também chega nele. Um receptor sem projeto recebe os eventos de qualquer projeto da conta, inclusive os que ainda não existem — desenho legítimo para quem integra um sistema só, e regra que ninguém deduz olhando a lista: um projeto criado depois passa a entregar num endereço que pode pertencer a outro sistema, de outro público. O motor não impede, porque repartir por conta ou por projeto é escolha de quem integra; o motor diz. Campo aditivo.

    GET /v1/webhooks/endpointsPOST /v1/webhooks/endpoints
  34. Novo

    O estado público diz até quando a fonte foi lida

    Cada capacidade do GET /status passa a trazer lastReadAt — quando a fonte respondeu bem pela última vez — e readThrough, até quando o conteúdo dela está lido. Até aqui a única maneira de obter essa data era pedir uma página de conteúdo e ler o índice que a resposta carrega, o que funciona quando há um recorte e não funciona quando a pergunta é sobre o acervo inteiro: quem publica uma página de cobertura ou de confiança não tinha a quem perguntar. readThrough vem preenchido onde existe uma data de conteúdo para o conjunto — hoje o diário, que publica por edição — e nulo onde a data vem com o recorte, na própria resposta da consulta. Campos aditivos, e a rota segue sem autenticação e cacheada por 30 segundos.

    GET /status
  35. Novo

    O aviso de movimentação diz o que aconteceu

    PROCESS_MOVEMENT_CREATED passa a trazer latestMovementCode e latestMovementLabel: o código da Tabela Processual Unificada e o nome do ato, para a movimentação que o evento anuncia. Até aqui o evento dizia que o processo andou e quantas vezes, e quem escreve um aviso tinha de reler a listagem de movimentações para descobrir o nome do ato que acabara de ser anunciado — uma chamada por evento, para um dado que o motor tinha em mãos no instante em que o emitiu. Campos aditivos, nulos quando a fonte não os declara — e nulos, com contentWithheld: true, quando o processo não é compartilhável: ali o nome do ato é teor, e o anúncio diz que o processo andou sem dizer o quê.

    PROCESS_MOVEMENT_CREATED
  36. Novo

    O processo diz se pode ser exibido

    Toda leitura de processo passa a trazer confidentiality (PUBLIC ou SEGREDO_DE_JUSTICA) e shareable — a classificação do motor sobre a linha, que é a mesma que decide a leitura compartilhada. Até aqui o único sinal no eixo do processo era sigiloLevel, o marcador da origem, que quase sempre vem vazio: quem exibe processo a um público não tinha como fechar a tela antes do teor. A publicação já trazia os dois campos; agora o processo os traz na busca, na leitura, no snapshot, nos relacionados e no resultado da busca assíncrona. Campos aditivos, sem custo adicional; ausentes numa linha do acervo gravada antes da capacidade.

    GET /v1/processes/{processNumber}POST /v1/processes/searchGET /v1/processes/{processNumber}/snapshotGET /v1/processes/{processNumber}/relatedGET /v1/search-jobs/{jobId}
  37. Novo

    O monitor de um alvo é encontrável pelo alvo

    Um monitor é único por alvo dentro da conta e do projeto, e pedir um segundo para o mesmo alvo responde 409 MONITOR_ALREADY_EXISTS. A recusa passa a trazer error.details.monitorId, o id do monitor que já vigia aquele alvo, e GET /v1/monitors passa a filtrar por alvo — tribunalAlias, processNumber, oabNumber, oabState, term e partyName —, nas mesmas grafias que a criação aceita. Quem mantém um sensor por alvo distinto seguia às cegas depois do 409: ou repaginava a conta inteira à procura do monitor, ou guardava o id por fora e divergia. Campos aditivos; a listagem continua a zero crédito.

    POST /v1/monitorsGET /v1/monitors
  38. Novo

    A movimentação diz o que ela é, sem abrir o payload

    GET /v1/processes/{processNumber}/movements passa a devolver code e label em cada item: o código da Tabela Processual Unificada e o nome do ato como a fonte o escreve. Os dois já viajavam dentro de payload, que continua carregando tudo o que carregava — complementos inclusive. O código é a chave por onde um consumidor traduz o ato para linguagem comum, e a listagem era a única superfície de movimentação que não o nomeava: o snapshot já o entregava. Campos aditivos, sem custo adicional; nulos quando a fonte não os declara.

    GET /v1/processes/{processNumber}/movements
  39. Mudou

    O 202 da busca de processos deixou de apagar os tipos do 200

    POST /v1/processes/search tem duas respostas de sucesso — 200 com o resultado e 202 com o descritor do job. O descritor era declarado aberto a campos extras, o que no tipo gerado do contrato vira um índice livre e apaga, na união das duas respostas, toda propriedade do lado síncrono: quem lia data.items recebia um tipo desconhecido, em silêncio. O 202 passa a declarar exatamente os campos que a rota emite — jobId, status, kind, pollUrl, deduped, creditsReserved e createdAt —, que são os mesmos de antes. Nada muda no que a rota responde; muda o que o contrato diz sobre ela, e agora um cliente tipado é levado a distinguir os dois casos em vez de adivinhar.

    POST /v1/processes/search
  40. Novo

    O catálogo diz onde cada tribunal aparece dentro do número

    GET /v1/tribunals passa a devolver cnjNumbering com segment e code — o J e o TR do número unificado (NNNNNNN-DD.AAAA.J.TR.OOOO). Quem recebe um número digitado ou colado por uma pessoa tinha o tribunal em mãos e nenhuma forma de nomeá-lo, porque a numeração não sai do número; a saída era manter uma tabela de noventa linhas por fora, que envelhece sozinha. Com o campo, um índice J.TR → alias montado uma vez a partir desta rota resolve qualquer número antes da primeira chamada que cobra. É nulo para o órgão fora do Judiciário, que não numera processo por esse padrão. Campo aditivo, sem custo adicional — a rota continua a zero crédito.

    GET /v1/tribunals
  41. Novo

    A publicação diz quem ela nomeia e de que órgão veio

    Toda publicação passa a trazer parties (nome e polo de quem ela nomeia), lawyers (nome, número e UF da inscrição) e courtBody (o órgão julgador) como campos próprios, em GET /v1/publications, GET /v1/publications/{publicationKey} e nas buscas por texto. Os três já viajavam dentro de metadata, que continua carregando tudo o que carregava — nada que chegava deixou de chegar, e integração que os lia por ali segue funcionando. Dependem da fonte: o eixo do diário nomeia os três, o acervo de jurisprudência nomeia só o órgão, e ali parties e lawyers chegam como lista vazia. Publicação sob segredo de justiça sai sem partes e sem advogados, como já saía sem teor. Campos aditivos, sem custo adicional.

    GET /v1/publicationsGET /v1/publications/{publicationKey}POST /v1/publications/text-searches
  42. Novo

    O resultado do job de busca também diz até onde o índice chegou

    GET /v1/search-jobs/{jobId} passa a devolver sourceIndex dentro de result, com o mesmo formato da busca síncrona: updatedThrough é a data até onde o índice do tribunal está atualizado e checkedAt, quando a busca montou a resposta com ela. Com ela, um total: 0 do modo assíncrono significa "ainda não chegou" quando a distribuição é posterior a updatedThrough. A mesma marca acompanha o total do aviso SEARCH_JOB_COMPLETED, para quem integrou por webhook em vez de poll. O campo é aditivo e acompanha o resultado que consultou a fonte; o job servido do acervo não o traz, e resultados concluídos antes desta data também não. Sem custo adicional.

    GET /v1/search-jobs/{jobId}Webhooks
  43. Mudou

    O status público separa lentidão de indisponibilidade

    GET /status não rebaixa mais uma capacidade quando parte das consultas excede o tempo de espera sem outra evidência de indisponibilidade. Timeouts parciais continuam na telemetria e nos alertas internos; respostas 5xx e falhas de conexão continuam produzindo DEGRADED ou OUTAGE. Se nenhuma consulta da amostra concluir, o componente segue como OUTAGE. O formato e os valores possíveis da resposta não mudaram, então nenhuma adaptação é necessária.

    GET /status
  44. Novo

    Resolver uma norma federal citada, no registro oficial e sob demanda

    POST /v1/legal-norms/resolve recebe a citação como ela é escrita — "Lei 8.078/1990, art. 6º, VIII", "CDC art. 6", "art. 5º, LXXVIII, da CF", "LC 123/2006", "MP 1.172/2023" — ou o par tipo, número e ano, e responde o que o registro oficial de normas federais declara sobre o ato: se ele consta, os apelidos pelos quais é citado, a ementa, quantas alterações permanentes sofreu e se foi revogado no todo, convertido em lei ou rejeitado. A consulta vai VIVA ao registro a cada chamada, então a resposta é a de agora, e nada do que ela lê fica guardado aqui. A resposta é explícita sobre o que NÃO prova: ela não confere o teor do artigo citado nem afirma que ele existe, e não afirma vigência — ausência de declaração de revogação não é prova de que a norma esteja em vigor, e por isso não existe um estado IN_FORCE. Três desfechos que se pareceriam com ausência vêm separados: NOT_FOUND (o ato não consta do registro), OUT_OF_REACH (o tipo de ato está fora do registro, que cobre lei, lei complementar, decreto-lei, decreto, medida provisória, emenda constitucional e a Constituição) e UNRECOGNIZED (a citação não foi entendida). Os dois últimos são decididos antes de qualquer consulta e não debitam crédito. A mesma capacidade está no canal agentic como resolver_norma_federal. A chave de teste recusa a porta: não há acervo de legislação a reler.

    POST /v1/legal-norms/resolveMCP
  45. Mudou

    A conferência de cobertura por nome confere o saldo antes de ir à fonte

    GET /v1/monitors/coverage-review vai VIVA ao diário e cobra como uma consulta por nome. A partir de agora ela confere a cota da conta antes de consultar, como as demais consultas cobradas: sem saldo, a resposta é 402 na hora, em vez de uma consulta que estoura o teto do ciclo. Quem tem saldo não nota diferença.

    GET /v1/monitors/coverage-review
  46. Mudou

    O push de um receptor que recusa há dias é suspenso, sem descartar nada

    Depois de 7 dias de recusa contínua o motor suspende o push do endpoint: nenhuma entrega nova nasce para ele até o titular retomar. A fila que já existia fica como está, os eventos seguem disponíveis pelos 180 dias de GET /v1/events e o titular é avisado por e-mail; o endpoint não é desativado. Retomar — POST /v1/webhooks/endpoints/{endpointId}/resume ou o portal — reabre o push e devolve replayFrom, o instante de onde reenviar por janela para repor o que nasceu sem entrega. GET /v1/webhooks/endpoints e /health ganham suspendedAt; /health ganha também oldestPendingAt. Junto: a sonda do endpoint espaçado insiste na MESMA entrega até ela esgotar as tentativas — uma entrega chega ao desfecho em cerca de 14 h de espaçamento, e a fila de um receptor parado tem saída; 404 e 410 esgotam em 3 tentativas em vez de 6; a entrega respeita o paywall como a varredura já respeitava, exceto os avisos comerciais, que atravessam; o reenvio por janela para endpoint suspenso responde 409 até a retomada, e o reenvio por evento pula o endpoint pausado ou suspenso; retomar um endpoint pausado pelo titular responde 409 — reative-o antes. O prazo conta a partir desta publicação para quem já estava recusando.

    /v1/webhooksGET /v1/eventsWebhooks
  47. Mudou

    O catálogo de tribunais diz o que serve cada tribunal

    sources de cada entrada passa a refletir as fontes que o motor tem daquele tribunal — o eixo de processo, o diário e, onde existe, o acervo de jurisprudência — em vez de repetir o mesmo par em toda linha; os valores do diário e do acervo são os de publication.source, e o eixo de processo, que nunca aparece numa publicação, tem valor próprio. O catálogo ganha o ramo ADMINISTRATIVE, do contencioso administrativo tributário federal, cujo acervo já respondia à pesquisa de jurisprudência sem constar da lista: para ele, consulta, assinatura e vigília de processo, busca e colheita no diário, recorte da vigília por tribunal e calendário forense recusam com TRIBUNAL_NOT_SUPPORTED — código que passa a constar do catálogo de erros — dizendo o que o tribunal serve; o calendário, que antes respondia 200 com a camada estadual vazia para essa sigla, passa a 400. A chave que liga uma publicação ao catálogo é code; alias identifica o tribunal só nas portas de processo. Cliente que valida branch ou sources em modo estrito precisa aceitar os valores novos.

    GET /v1/tribunalsPOST /mcp
  48. Novo

    A vigília diz o que a fonte disse

    O monitor de processo ganha sourceUpdatedAt e latestMovementAt: a data em que a fonte diz ter atualizado o processo e a data do movimento mais recente que ela conhece, como a última varredura as leu. As duas saem também no evento MONITOR_SYNC_SUCCEEDED. O hash da varredura responde "mudou ou não"; só estas datas separam "sem mudança" de "fonte parada" — um processo que migra de sistema no tribunal fica semanas estável no índice nacional. No canal agentic saem como fonteAtualizadaEm e ultimoMovimentoEm no resumo do monitor.

    /v1/monitors/mcp
  49. Mudou

    O handshake nomeia o que a credencial não alcança

    As instruções de initialize passam a listar as tools que a credencial não alcança e que por isso não aparecem em tools/list, com o caminho para reautorizar. A descrição de uma tool visível pode citar uma escondida, e sem a ressalva o agente lia o nome de uma tool que o host não lhe entregou e concluía que ela não existia.

    POST /mcp
  50. Novo

    A vigília diz quem a parou

    O monitor ganha retiredAt: preenchido quando foi o motor quem parou a vigília, por cadastro que a fonte diz não existir ou que não descreve um alvo consultável; nulo com status: PAUSED significa que quem parou foi o titular. As duas pausas pediam conduta oposta de quem lê e chegavam como a mesma palavra. No canal agentic o mesmo dado sai como aposentadoPeloMotor no resumo do monitor.

    /v1/monitors/mcp
  51. Mudou

    O calendário forense traz os feriados nacionais e o recesso

    Os feriados nacionais de data fixa e o recesso de 20/12 a 20/1 deixam de ser dever de quem chama e passam a vir na resposta. O recesso vem com kind: RECESS — nele o curso do prazo fica suspenso, o que é diferente de dia sem expediente —, e uma data pode aparecer nas duas naturezas, como 25/12. 20/11 só é expandido a partir de 2024, ano em que passou a valer. Quem já aplica essas camadas filtra por scope NATIONAL. Na Justiça Eleitoral o recesso não é afirmado: o regime de prazos dela é próprio.

    /v1/court-calendar/mcp
  52. Mudou

    O calendário forense alcança todo tribunal de jurisdição estadual

    A camada estadual deixa de valer só para tribunal de justiça: passa a alcançar o regional do trabalho, o regional eleitoral, o militar estadual e a 6ª região federal — todo tribunal cuja jurisdição é de um estado. É o mesmo princípio que já rege a camada municipal: a comarca fecha para quem ali funciona, seja qual for a justiça. Onde a jurisdição abrange mais de uma UF, ou é nacional, a camada continua declarada indisponível — nunca deduzida. A resposta ganha jurisdiction, com o alcance do tribunal e as UFs em jogo.

    /v1/court-calendar/mcp
  53. Novo

    O calendário forense declara o que consultou

    A resposta ganha coverage: camada a camada — feriados nacionais móveis e de data fixa, recesso do art. 220, estaduais, municipais e suspensão de expediente —, se ela entrou na lista e, quando não, o código do motivo. Janela sem entradas deixa de ser ambígua: CONSULTED é o único estado em que a ausência de dia significa que não há. A mesma declaração fecha a resposta da tool consultar_calendario_forense.

    /v1/court-calendar/mcp
  54. Mudou

    A cobertura por matéria é uma declaração

    A matéria fora do acervo continua na lista, com covered: false, e o campo note sai do payload de areas. O que a rota responde é se a matéria está no acervo — resultado vazio nunca se confunde com matéria não coberta, que é para o que a lista existe.

    /v1/publications/corpus/coverage/public/coverage-areas
  55. Novo

    O canal agentic alcança o calendário forense e a busca por expressão

    Quatro tools novas: consultar_calendario_forense devolve os dias sem expediente de um tribunal — feriado móvel, estadual e municipal da comarca —, reabrir_pesquisa_jurisprudencia pagina o ranking congelado de uma pesquisa pelo searchId, sem cobrar e sem mudar as posições, e excluir_monitor apaga a vigília em definitivo, encerrando também a base de interesse legítimo que pausar mantém, e listar_tribunais devolve o catálogo de onde sai a grafia que as demais aceitam. buscar_publicacoes passa a aceitar text e tribunalCode, os dois eixos que a rota GET /v1/publications já publicava.

    POST /mcp
  56. Novo

    O evento diz quando o teor não acompanha o item

    O payload de entrega ganha contentWithheld: true no item cujo teor não é entregue. Três causas levam ao mesmo desfecho — segredo de justiça, bloqueio de exibição pedido pelo titular e linha que já saiu do acervo —, e o campo não distingue qual foi: a conduta é a mesma. Antes, teor ausente e teor inexistente chegavam idênticos, com excerpt nulo e sem explicação. O campo aparece no topo do payload e em cada item de matches, e é decidido na leitura, não na gravação.

    WebhooksGET /v1/eventsPOST /mcp
  57. Novo

    A recusa por volume da fonte declara quanto esperar

    Quando a fonte responde 429 com Retry-After, o motor o repassa: a resposta de erro traz o cabeçalho Retry-After e os detalhes trazem retryAfterSeconds. É a mesma distinção que a taxonomia já fazia entre o 429 do plano e o da fonte, agora com o prazo declarado.

    /v1POST /mcp
  58. Novo

    A vigília de termo e de parte aceita recorte por tribunal

    POST /v1/monitors passa a aceitar tribunalAlias — pela sigla ou pelo apelido — nos tipos TERM e PARTY. Sem ele a varredura continua nacional, que é o padrão. Com ele, a vigília lê só aquele tribunal: é o que tira o alvo comum da parede de deslocamento do diário, que num dia pesado deixa cauda por ler. O monitor devolve o recorte em tribunalSigla, e as tools criar_monitor_de_termo e criar_monitor_de_parte recebem o mesmo recorte em tribunal.

    POST /v1/monitorsPOST /mcp
  59. Novo

    A cobertura do acervo é declarada por matéria

    A cobertura do corpus ganha o campo areas: para cada matéria — Justiça estadual, federal, trabalhista, militar, direito federal infraconstitucional e tributário administrativo — o estado (NONE, PARTIAL, INDEXED), as contagens e os tribunais com documento indexado. As matérias fora do acervo vêm na mesma lista com covered: false, para que resultado vazio nunca se confunda com matéria não coberta. A tool de pesquisa de jurisprudência repete a declaração quando nada casa.

    /v1/publications/corpus/coveragePOST /mcp
  60. Novo

    A publicação explica quando o teor não veio

    O item de publicação ganha o campo opcional textUnavailable. Vale OBJECT_MISSING quando o teor existe fora do banco e o armazenamento não o tem — anomalia de infraestrutura que uma nova consulta não resolve — e fica ausente quando o texto veio ou quando a fonte nunca trouxe teor. Está presente em toda superfície que serve o item: leitura por chave, busca no diário e reabertura de busca textual com hydrate.

    /v1/publications/v1/publications/text-searchesPOST /mcp
  61. Novo

    A tool novidades informa quanto ainda falta ler

    Quando os eventos não cabem numa chamada sem argumentos, a resposta passa a dizer quantos ainda faltam e o instante do mais antigo pendente, para o agente saber quantas chamadas o separam do presente. O marcador e a entrega continuam iguais; a leitura explícita com desde ou monitorId segue sem medir atraso, porque a janela é do chamador.

    POST /mcp

agosto de 2026

  1. Novo

    Monitor de nome de parte: saiba quando processam quem você vigia

    POST /v1/monitors aceita type: "PARTY" com partyName e alcança até o aviso de distribuição, a primeira notícia de uma ação nova. Informe o nome inteiro como consta no registro (para empresa, a razão social): nome parcial casa com terceiros de nome mais longo e é descartado. Cada PUBLICATION_CREATED traz partyName e partyRole; publicação sob sigilo não é anunciada. O monitor conta na mesma vaga do monitor de termo.

    POST /v1/monitorsGET /v1/monitorsPOST /mcp
  2. Novo

    O inteiro teor do acórdão de tribunal superior entra no acervo

    O acervo de tribunal superior passa a incluir o acórdão publicado, com documentKind: ACORDAO, além do espelho de ementa e campos estruturados. A busca e a leitura continuam sobre a ementa, que é o resumo que o tribunal escreve; o texto integral do julgado viaja no payload bruto da publicação (rawPayload), para quem pede includeRaw na listagem. Nenhum endpoint muda de forma: o acervo ampliado aparece sozinho na busca textual, na cobertura e na tool pesquisar_jurisprudencia.

    /v1/publications/v1/publications/text-searches/v1/publications/corpus/coveragePOST /mcp
  3. Mudou

    publication.source ganha acervos novos e nasce documentKind

    publication.source passa a ter valores novos, um por acervo estruturado de jurisprudência, então quem valida o campo em modo estrito precisa aceitar os valores listados no OpenAPI; quem o trata como texto não muda nada. Vai junto o campo aditivo publication.documentKind, que diz se a linha é a decisão (ACORDAO), o espelho dela (ESPELHO) ou a intimação que a anuncia (INTIMACAO).

    /v1/publications/v1/publications/text-searchesPOST /mcp
  4. Novo

    Precedentes qualificados: temas e teses de tribunal superior

    GET /v1/precedents busca temas de precedente qualificado pela questão submetida e pela tese firmada, com filtros por tipo, número, situação e presença de tese; GET /v1/precedents/{id} detalha o tema com referências e processos paradigma. Cada chamada custa 1 crédito (PRECEDENT_READ), e a situação acompanha o julgamento. No canal agentic, a tool consultar_precedentes cobre a mesma consulta e traz o detalhe quando o recorte resolve a um único tema.

    /v1/precedentsPOST /mcp
  5. Novo

    Monitor de processo aceita alvo que a fonte ainda não indexou

    Um monitor de processo cujo alvo ainda não apareceu no índice da fonte é aceito e espera: targetSeenAt: null marca a espera, MONITOR_SYNC_SUCCEEDED sai com awaitingAppearance: true e a primeira aparição chega com firstAppearance: true, seguida das movimentações. Informe distributedAt (AAAA-MM-DD, nunca no futuro, só em monitor de processo) para o motor só consultar o alvo quando o índice alcançar essa data.

    /v1/monitors/v1/webhooksPOST /mcp
  6. Novo

    A busca de publicações diz qual foi a última edição detectada

    Toda resposta de GET /v1/publications traz sourceIndex.lastEditionDate, a última edição do diário que o motor detectou. Com ela, um resultado vazio sem a edição do dia significa "ainda não saiu", não "não existe"; a prova vale numa direção só — com a edição detectada, zero ainda não prova ausência, porque a edição no ar recebe itens ao longo do dia. sourceItemCount, o tamanho da página como a fonte a devolveu, passa a constar no contrato.

    /v1/publications
  7. Novo

    Tools de gestão do canal agentic respondem dado tipado

    As tools de monitores e de saldo declaram outputSchema em tools/list e devolvem structuredContent junto do texto, para o host consumir o resultado sem parsear prosa. As tools que servem teor de publicação continuam respondendo só texto, com o teor demarcado como conteúdo de terceiros.

    POST /mcp
  8. Novo

    Varredura imediata de monitor e cancelamento de job de busca

    POST /v1/monitors/{monitorId}/sync agenda uma varredura imediata: o monitor entra no próximo ciclo, em cerca de um minuto, e o resultado chega pelos eventos e webhooks de sempre. POST /v1/search-jobs/{jobId}/cancel cancela um job de busca ainda não concluído da própria conta e devolve a retenção de créditos na hora.

    /v1/monitors/v1/search-jobs
  9. Novo

    Reenvio de webhooks por janela de tempo

    POST /v1/webhooks/endpoints/{endpointId}/replay reenfileira, para um endpoint, os eventos assinados ocorridos entre from e to, criando as entregas que faltam e devolvendo à fila as que falharam ou foram canceladas; includeDelivered: true reenvia também o que já chegou. Quando a resposta trouxer skipped maior que zero, repita com from = nextFrom para continuar.

    /v1/webhooks
  10. Mudou

    A publicação de hoje chega no ciclo em que sai

    A varredura de monitor de publicação lê primeiro a edição mais recente, então a publicação do dia chega no mesmo ciclo. No MONITOR_SYNC_SUCCEEDED, resumesAt aponta o dia mais antigo por ler, pendingDays diz quantos dias ainda têm página pendente e coveredThrough avança só pelo trecho contíguo coberto.

    /v1/monitors
  11. Mudou

    Receptor que recusa recebe com espaçamento crescente, e há como retomar

    Cinco recusas seguidas no mesmo endpoint espaçam as entregas dele em intervalos crescentes, de 15 minutos a 6 horas; ao fim de cada intervalo uma entrega passa como sonda, e qualquer resposta 2xx devolve o ritmo normal na hora. Nada é descartado e o endpoint não é desativado; o que muda é a cadência, e com ela o tempo até uma entrega esgotar as seis tentativas. Toda entrega leva x-lexnode-delivery-attempt e x-lexnode-endpoint-failures, e x-lexnode-endpoint-warning quando a próxima recusa vai espaçar a fila. Para retomar sem esperar a sonda: POST /v1/webhooks/endpoints/{endpointId}/resume.

    /v1/webhooks
  12. Novo

    Saúde de webhook, uso por sub-conta e colheita ganham campos novos

    GET /v1/webhooks/health traz consecutiveFailures e retryPausedUntil por endpoint, e GET /v1/usage ganha backgroundWork em cada linha de sub-conta, separando o trabalho que o motor faz na agenda dela das requisições que o consumidor fez. O progresso de fatia de colheita ganha itemsNew, a linha que passou a existir no acervo, distinta de itemsPersisted.

    /v1/webhooks/v1/usage
  13. Mudou

    A falha de monitor diz a causa e se vale repetir

    MONITOR_SYNC_FAILED ganha code, class e retryable: um processo que não existe na fonte (PROCESS_NOT_FOUND, terminal) se distingue de uma indisponibilidade momentânea, e o consumidor separa o que passa sozinho do que só ele resolve. O campo error traz a mensagem classificada, e o extrato de uso registra o status da causa — processo inexistente aparece como 404.

    /v1/webhooks/v1/events/v1/usage
  14. Novo

    O agente busca no diário e cria vigília de OAB e de processo

    Três tools novas no canal agentic: buscar_publicacoes responde o que saiu no diário para um processo ou para uma inscrição na OAB numa janela de datas, pelo mesmo preço do GET /v1/publications — 2 créditos por processo, 5 por OAB; criar_monitor_de_oab e criar_monitor_de_processo completam a criação de monitor, ao lado do de termo. Nenhuma exige escopo além do preset do agente, então aparecem para quem já está conectado, sem reautorizar.

    POST /mcp
  15. Novo

    O agente consulta processo e pesquisa jurisprudência

    consultar_processo devolve o retrato de um processo pelo número único e pela sigla do tribunal: classe, assunto, órgão julgador e movimentos. pesquisar_jurisprudencia busca sobre ementa e tese do acervo, congela o resultado e devolve os acertos com a citação e a publicationKey; reabrir a busca congelada não cobra.

    POST /mcp
  16. Mudou

    O catálogo de tools mostra só o que a credencial alcança

    tools/list é filtrado pelos escopos da chave que autenticou a chamada, então cada conexão enxerga exatamente as tools que pode usar. Reautorizar a conexão concede o preset de escopos vigente e faz uma tool nova aparecer.

    POST /mcp
  17. Novo

    novidades aceita janela de datas e recorte por monitor

    A tool novidades ganha desde, ate e monitorId, os mesmos recortes de GET /v1/events. Informar qualquer um deles torna a leitura explícita e não move o marcador do servidor, o que permite reler uma janela já lida ou perguntar o que um monitor específico encontrou; a chamada sem argumentos continua entregando o delta desde a última vez.

    POST /mcp
  18. Novo

    Conexão nativa do canal agentic: basta colar o endereço no agente

    POST /mcp passa a ser um resource server OAuth: o hospedeiro descobre a metadata nos endereços .well-known, registra o cliente e conduz o login numa tela do portal, com escopo agent e teto diário de créditos. Autenticação por cabeçalho Bearer segue valendo para ambiente sem navegador.

    POST /mcpGET /.well-known/oauth-protected-resourceGET /.well-known/oauth-authorization-serverPOST /oauth/registerPOST /oauth/tokenPOST /oauth/revoke
  19. Mudou

    POST /mcp pede credencial em todos os métodos

    initialize, ping e tools/list autenticam como tools/call já fazia; credencial ausente, inválida ou vencida recebe o desafio WWW-Authenticate, que é o que faz o hospedeiro oferecer a tela de login. Recusas de negócio (cota, teto diário, plano) continuam em banda; integrações que já enviam o cabeçalho Bearer em toda requisição não mudam.

    POST /mcp
  20. Novo

    Canal agentic: conecte seu agente de IA via MCP

    POST /mcp fala Model Context Protocol autenticado pela mesma API key, com tools para criar e gerenciar monitores, ler as novidades desde a última chamada, ler publicação e consultar saldo. Toda resposta informa custo e saldo, o teor de publicação vai demarcado como conteúdo não confiável, e o uso cai no mesmo medidor de créditos da API.

    POST /mcp
  21. Novo

    Escopo EVENTS_READ e teto diário de créditos por chave

    GET /v1/events e GET /v1/events/{eventId} pedem o escopo dedicado EVENTS_READ; chaves antigas com USAGE_READ continuam funcionando ali. A criação de chave aceita variant: AGENT (credencial destinada a agentes de IA) e maxCreditsPerDay: no estouro, operações com custo respondem API_KEY_DAILY_CAP_EXCEEDED e as de custo zero seguem funcionando.

    GET /v1/eventsGET /v1/events/{eventId}POST /mcp
  22. Novo

    Monitor de termo: vigie o diário oficial por texto livre

    POST /v1/monitors aceita type: "TERM" com um termo livre; o motor varre a edição diária em escala nacional, casa o termo por palavra inteira (com flexões de plural) e emite PUBLICATION_CREATED com o campo term no payload para cada menção compartilhável nova. Publicação sob sigilo não é anunciada, e o teto de monitores de termo é próprio.

    POST /v1/monitorsGET /v1/monitors
  23. Novo

    A busca de processos diz até onde o índice da fonte chegou

    POST /v1/processes/search devolve sourceIndex.updatedThrough, a data até onde o índice do tribunal está atualizado. Antes de concluir que um processo não existe, compare com a data de distribuição: um processo distribuído depois dela ainda não é encontrável, e um resultado vazio ali significa "ainda não chegou", não "não existe". Sem custo adicional.

    POST /v1/processes/search
  24. Novo

    Estado público do motor em GET /status

    GET /status responde, sem autenticação, o estado operacional de cada capacidade: consulta processual, publicações, processamento assíncrono e entrega de webhooks. É estado, nunca volume, e a resposta é cacheada por 30 segundos.

    GET /status
  25. Novo

    A busca textual pode trazer o teor na mesma chamada

    POST /v1/publications/text-searches aceita hydrate: true e devolve o teor de cada acerto já na criação, com publication e redacted em cada item e redactedCount na resposta. É a mesma reabertura gratuita, feita na mesma chamada, sem crédito adicional.

    POST /v1/publications/text-searches
  26. Novo

    Política de versionamento e headers de depreciação

    A superfície declara o que promete: mudança aditiva entra a qualquer momento, quebra não entra em /v1, e desligar uma rota exige anúncio com prazo mínimo. Rota depreciada responde com os headers Deprecation, Sunset e Link, e a lista fica legível por máquina em GET /.

    GET /DeprecationSunsetLink
  27. Novo

    GET /ready diz quando a instância pode receber tráfego

    GET /ready responde 503 enquanto a instância encerra ou o banco não responde, para um balanceador tirá-la de rotação; GET /health consulta o banco e responde 503 quando ele não responde. É neles que se aponta o monitor externo.

    GET /healthGET /ready
  28. Mudou

    As rotas de assinatura de processo pedem escopo próprio

    /v1/subscriptions passa a exigir SUBSCRIPTIONS_READ e SUBSCRIPTIONS_WRITE, em vez de viajar no escopo de monitores. As chaves já existentes receberam os dois escopos; uma chave nova precisa pedi-los para alcançar essas rotas.

    /v1/subscriptions
  29. Novo

    A leitura de publicação devolve o acórdão já extraído

    GET /v1/publications/{publicationKey} traz um bloco caseLaw com ementa, tese, as seções padronizadas da ementa, relator, órgão julgador, classe e data de julgamento, junto do extractorVersion que os produziu. Sem crédito adicional; é null quando a publicação não é julgado.

    GET /v1/publications/{publicationKey}
  30. Mudou

    O tribunal se escreve como quem integra o escreve

    Os eixos de publicações e de processos aceitam tanto a sigla do tribunal quanto o apelido dele, e o calendário forense recebe o tribunal em court. O parâmetro tribunalAlias continua valendo como sinônimo; nada que já funcionava deixou de funcionar.

    /v1/publications/v1/processes/v1/court-calendar
  31. Novo

    O teto por minuto sai em toda resposta

    Os headers RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset acompanham qualquer resposta autenticada, não só a recusa, para o cliente se regular antes de bater no teto. Na recusa, Retry-After diz quanto esperar.

    RateLimit-LimitRateLimit-RemainingRetry-After
  32. Mudou

    error.class e error.retryable entram no contrato de erro

    O envelope de erro documenta todos os campos que a resposta carrega: class e retryable dizem se a falha é transitória e se vale repetir. A recusa por cota esgotada passa a constar em todas as operações autenticadas do documento.

    error.classerror.retryable402
  33. Mudou

    Leitura do acervo não consome o teto diário

    O limite diário conta apenas as requisições que consultam a fonte externa; leitura servida do acervo já colhido não entra nele, então uma integração que lê muito não é freada pelo que não custa.

    429 RATE_LIMIT_EXCEEDED