Monitoramento customizado
Essa página tem como objetivo mostrar o fluxo de Monitoramento cutomizado
O monitoramento customizado permite monitorar processos utilizando filtros específicos, retornando processos de todos os tribunais que correspondem aos critérios definidos. Essa consulta é ideal para identificar processos com características específicas em um amplo espectro de jurisdições. Para utilizá-la, é necessário enviar uma requisição ao endpoint correspondente.
Para este tipo de consulta, certifique-se sobre a precificação, pois não é a mesma da consulta histórica.
Criação do monitoramento
Payload da Solicitação
A solicitação POST deve incluir um payload com as seguintes propriedades:
search_type: Este campo define o tipo de entidade que será buscada, para monitoramento customizado, terá sempre o valor custom
;
-
search_key
: Este campo define o valor da entidade que será buscada, para monitoramento customizado, terá sempre o valorcustom
; -
cache_ttl_in_days
(opcional): Número inteiro que define até quantos dias o resultado da busca pode considerar um cache válido; -
search_params
: Um objeto que contém alguns parâmetros da busca como: -lawsuit_instance
(opcional): Este parâmetro permite definir a instância em que deseja buscar o processo; -masked_response
Define se a resposta virá minificada. Este parâmetro é aplicável apenas a consultas (simples ou completas) no contexto de busca processual. - masked_response =true
: retornará uma consulta completa - masked_response =false
: retornará uma consulta simples*Obs
Consulte as condições comerciais desses diferentes tipos de monitoramento customizado.
Filtros poderão ser adicionados à requisição, permitindo um retorno mais assertivo com base nos valores desejados. Para isso, o parâmetro filter
deve ser incluído dentro de search_params
, com os seguintes filtros disponíveis:
-
filter
(opcional): Um objeto que contém os filtros para a busca, como: -
side
(opcional): Permite buscar por tipos de participantes do processo, podendo ser: ‘Passive’, ‘Active’, ‘Interested’, ‘Unknown’; -
amount_gte
(opcional): Filtra processos com valor da causa maior ou igual ao especificado emamount_gte
; -
amount_lte
(opcional): Filtra processos com valor da causa menor ou igual ao especificado emamount_lte
; -
tribunals
(opcional): Um objeto que contém os filtros de tribunais:keys
(opcional): Lista de códigos de tribunais disponíveis na lista de tribunais. Este filtro permite restringir a busca a processos que tenham ou não esses códigos específicos;not_equal
(opcional): Valor booleano que define se o filtro incluirá ou excluirá os valores especificados emkeys
.
-
subject_codes
(opcional): Um objeto que contém os filtros de assuntos:contains
(opcional): Lista de códigos de assuntos. Restringe a busca a processos que incluam os códigos especificados.not_contains
(opcional): Lista de códigos de assuntos. Exclui processos que contenham os códigos especificados.
-
classification_codes
(opcional): Um objeto que contém os filtros de classes processuais:keys
(opcional): Lista de códigos de classes processuais. Este filtro permite restringir a busca a processos que tenham ou não esses códigos específicos;not_equal
(opcional): Valor booleano que define se o filtro incluirá ou excluirá os valores especificados emkeys
.
-
distribution_date_gte
(opcional): Permite especificar uma data mínima de distribuição. Este filtro localiza processos distribuídos após a data informada. -
credential
(opcional): Objeto para o uso do cofre de credenciais: -
customer_key
(opcional): Permite passar a chave do usuário cadastrada no cofre de credenciais. Caso não seja informada, a API tentará encontrar uma credencial cadastrada para umacustomer_key
vazia. -
last_step_date_gte
(opcional): Restringe a busca a processos cuja data da última movimentação seja maior que à data fornecida. -
last_step_date_lte
(opcional): Restringe a busca a processos cuja data da última movimentação seja menor que à data fornecida. -
party_names
(opcional): Lista de nomes que restringe a busca a processos que os contenham em alguma das partes.Obs
Ao utilizar esse filtro em conjunto com o filtro deSide
, o filtro deSide
não será considerado para a restrição dessas partes, já que o filtro deSide
é utilizado para filtrar processos onde a parte principal buscada esteja no lado especificado. -
party_documents
(opcional): Lista de documentos que restringe a busca a processos que os contenham em alguma das partes.Obs
Ao utilizar esse filtro em conjunto com o filtro deSide
, o filtro deSide
não será considerado para a restrição desses documentos, já que o filtro deSide
é utilizado para filtrar processos onde a parte principal buscada esteja no lado especificado.
Todos os monitoramentos customizados cadastradas são realizadas on-demand. Recomendamos verificar as condições de custo associadas a este serviço antes de sua utilização.
Retorno:
O monitoramento irá ser iniciado a primeira vez, na melhor janela de concorrência de requisição ao tribunal, dentro das próximas 24 horas da data de criação.
Depois ocorrerá de acordo com a frequeência cadastrada no campo recurrence.
Consultar o status do monitoramento
Na URL vai o tracking_id retornado na primeira requisição:
Retorno:
A propriedade status informa a situação atual do monitoramento, podendo ser:
created: Monitoramento criado, porém nunca executado.
updating: Está com uma requisição em processamento.
updated: Monitoramento atualizado já com alguma resposta disponível. O campo updated_at pode informar a data de última atualização do monitoramento e a propriedade request_id o id da última request feita pelo monitoramento.
paused: Monitoramento pausado, podendo ainda ser reativado.
deleted: Monitoramento cancelado e não pode mais ser reativado.
A propriedade request_id só é criada a partir da primeira vez que o monitoramento executou, ou seja, chegou ao status updated.
Consultar o conteúdo da resposta (nova ação encontrada)
Na URL vai o request_id retornado na primeira requisição:
O parâmetro page e page_size são opcionais, porém necessários para percorrer as páginas com os processos, caso venham mais de uma, o que é comum no caso de consulta por documento.
No caso de monitoramento customizadoo, ele sempre será de novas ações, ou seja, as requisições só gerarão respostas caso um novo processo seja distribuído a partir da data em que foi cadastrado.
O significado de cada campo pode ser encontrado no glossário:
Consultando histórico de um monitoramento
Para consultar o histórico de respostas geradas por um monitoramento específico, faça uma solicitação GET para a rota /tracking/, substituindo pelo ID do monitoramento desejado.
Você pode filtrar os resultados usando os parâmetros created_at_gte
e created_at_lte
, onde:
created_at_gte
: define a data inicial da consulta.
created_at_lte
: define a data final da consulta.
Aqui está um exemplo de como fazer isso usando curl:
Aqui está o retorno esperado:
Pausando um Monitoramento
Para pausar um monitoramento, você pode fazer uma solicitação POST para a rota /tracking/{monitoramento}/pause
, substituindo {monitoramento}
pelo ID do monitoramento que você deseja pausar.
Aqui está um exemplo de como pausar o monitoramento usando o curl:
Aqui está um exemplo de retorno do monitoramento pausado:
Reativando um Monitoramento
Para reativar um monitoramento pausado, você pode fazer uma solicitação POST para a rota /tracking/{monitoramento}/resume
, substituindo {monitoramento}
pelo ID do monitoramento que você deseja reativar.
Aqui está um exemplo de como reativar um monitoramento usando curl:
Aqui está um exemplo de retorno do monitoramento ativo
Deletando um Monitoramento
Para deletar um monitoramento, você pode fazer uma solicitação DELETE para a rota /tracking/{monitoramento}
, substituindo {monitoramento}
pelo ID do monitoramento que você deseja deletar.
Aqui está um exemplo de como deletar um monitoramento usando curl:
Aqui está um exemplo do retorno do monitoramento deletado: