Monitoramento

A API de Monitoramento permite o registro de nomes e processos para serem monitorados diariamente nos tribunais e diários oficiais.

A seguir ilustramos seu funcionamento.

Visão geral do funcionamento da API de monitoramento

• Preliminarmente, as pessoas e processos monitorados são registrados usando as chamadas das seções seguintes. Estes registros são feitos associados a empresas na API.
• No passo 1, obtemos junto aos sistemas online dos tribunais e seus diários oficiais os novos processos distribuidos envolvendo as partes de interesse. Para os processos em tribunais digitalizados, obtemos também uma cópia da inicial e demais anexos de cada processo.
• No passo 2, realizamos o tratamento desses dados, realizando checagens de dados das partes junto a cadastros da Receita Federal, filtramos apenas para as localidades, partes ou assuntos/naturezas de processos de interesse.
• No passo 3, as novas informações de processos e pessoas que passem nos filtros e regras de negócio são realizados diretamente no sistema ERP, ou retornados via esta API, evitando erros de digitação. O cliente pode pedir todas as informações disponíveis, ou o Digesto pode realizar uma chamada HTTP no sistema do Cliente apenas com as novas informações, movimentações etc. Esta chamada realizada pela API Digesto é feita via um HTTP POST, no formato descrito em Eventos.

Tipos

Os seguintes tipos de monitoramento estão disponíveis:

Tipo de evento (evt_type) = 2 [Código do Produto: DIA_EM_Publicacao]

Nota

Requer módulo “(API) Monitorar distribuições” (quando monitorando publicações de parte) ou “(API) Monitorar andamentos e mudanças cadastrais de processos” (quando for processo monitorado).

Critério de Monitoramento: palavras, nome, OAB, CPF, CNPJ de parte (pessoa física, jurídica, advogado). (monitored_person)

Fonte de Monitoramento: Publicações em Diários Oficiais Judiciais

Resposta da API: compreenderia qualquer menção aos nomes monitorados nos recortes judiciais, que pode indicar tanto novos processos distribuídos quanto publicações de processos existentes.

Tipo de evento (evt_type) = 4 [Código do Produto: Novas Distribuições (com e sem anexos) PCS_EM_Distribuicao]

Nota

Requer módulo “(API) Monitorar andamentos e mudanças cadastrais de processos”

Critério de Monitoramento: palavras, nome, OAB, CPF, CNPJ de parte (pessoa física, jurídica, advogado) (monitored_person)

Fonte de Monitoramento: Tribunais

Resposta da API: detalhes completos dos processos recém-distribuídos, frequentemente antes de qualquer publicação em diários oficiais e bem antes da citação física via correio.

Tipo de evento (evt_type) = 3 [Código do Produto: DIA_EM_PublicacaoDiarioTermoGeral_INT]

Nota

Requer módulo “(IP) Diários Oficiais: buscar”

Critério de Monitoramento: palavras (monitored_term)

Fonte de Monitoramento: Diários Oficiais judiciais, administrativos, legislativos, executivos.

Resposta da API: trecho do diário oficial que menciona a palavra monitorada. Por se tratar de publicações judiciais ou não, nesta modalidade o resultado não vem estruturado como recorte com campos.

Tipo de evento (evt_type) = 2 [Código do Produto: DIA_EM_Publicacao]

Nota

Requer módulo “(API) Monitorar andamentos e mudanças cadastrais de processos”

Critério de Monitoramento: número de processo (proc)

Fonte de Monitoramento: Publicações em Diários Oficiais Judiciais

Resposta da API: novas publicações dos processos pre-existentes/conhecidos.

Tipo de evento (evt_type) = 1 (mov.), 7(outros) [Código do Produto: PCS_EM_Andamento_INT | PCS_EM_DiferencaProc_INT]

Nota

Requer módulo “(API) Monitorar andamentos e mudanças cadastrais de processos”

Critério de Monitoramento: número de processo (proc)

Fonte de Monitoramento: Tribunais

Resposta da API: movimentações, mudanças (audiências, novos advogados, novos anexos). Também chamado de push processual.

Tipo de evento (evt_type) = 11

Critério de Monitoramento: Web site (Endereço HTTP/URL) (monitored_url)

Fonte de Monitoramento: Conteúdo texto das páginas

Resposta da API: palavras e linhas modificadas no site monitorado após acessá-lo diversas vezes ao dia.

Tipo de evento (evt_type) = 10 [Código do Produto: PCN_EM_Reclamacao]

Nota

Requer módulo “(API) Monitorar Procon”

Critério de Monitoramento: Login da empresa no site do PROCON

Fonte de Monitoramento: SINDECs estaduais e municipais e alguns outros sistemas PROCON

Resposta da API: dados completos da reclamação registrada pelo consumidor nos sites do PROCON eletrônico (SINDEC e outros).

Tipo de evento (evt_type) = 13 [Código do Produto: PCS_CH_AtualizacaoTribunal]

Nota

Requer módulo “(API) Monitorar andamentos e mudanças cadastrais de processos”

Critério de Monitoramento: Um pedido de atualização de processo no tribunal. (ver Exemplo de retorno webhook com evento descrevendo que um processo judicial foi atualizado)

Fonte de Monitoramento: Tribunais

Resposta da API: dados completos do processo atualizado.

Cobertura

Veja a listagem completa e atualizada dos tribunais em todas as instâncias suportadas.

O monitoramento dos Diários Oficiais também é feito de forma diária. Veja Cobertura de diários oficiais monitorados.

Recomendamos inscrever seu e-mail para receber atualizações da cobertura.

GET https://op.digesto.com.br/api/tribproc/status_cobertura

Retorna JSON com os dados da cobertura. Realizar uma chamada por área.

Exemplo de chamada:

GET https://op.digesto.com.br/api/tribproc/status_cobertura?area=estadual HTTP/1.1
Accept: application/json

Exemplo de resposta:

HTTP/1.1 200 OK
Content-Type: application/json


{
    "majorDimension": "ROWS",
    "range": "Superior!A1:Z1003",
    "values": [
        [
            "Tribunal",
            "Estado(s)",
            "Sistema",
            "Inst\u00e2ncia",
            "Distribui\u00e7\u00e3o",
            "Anexos",
            "Andamentos",
            "Publica\u00e7\u00f5es",
            "Intima\u00e7\u00e3o",
            "Peticionamento",
            "Certid\u00e3o",
            "Info"
        ],
        [
            "STF",
            "\u2013\u2013",
            "Pr\u00f3prio",
            "\u2013\u2013",
            "N\u00e3o",
            "Sim",
            "Sim",
            "Sim",
            "N\u00e3o",
            "N\u00e3o",
            "N\u00e3o"
        ],
        [
            "STJ",
            "\u2013\u2013",
            "Pr\u00f3prio",
            "\u2013\u2013",
            "N\u00e3o",
            "Sim",
            "Sim",
            "Sim",
            "N\u00e3o",
            "N\u00e3o",
            "N\u00e3o"
        ]
    ]
}

Query Parameters:  

• area (string) – área da justiça a ser retornada. Valores válidos: estadual, trabalhista, federal, superior.

Frequência de monitoramento

Todos os processos e nomes monitorados são consultados pelo menos uma vez ao dia junto aos sites dos tribunais correspondentes.

Novas distribuições

O monitoramento de novas distribuições demora cerca de três dias até se tornar efetivo.

Para ser resultado de uma distribuição, a data de distribuição de um processo deve atender todos os três critérios:

• superior à data de hoje menos a quantidade de dias retroativos configurado para a parte. Apenas Digesto pode modificar essa quantidade. Ela possui valor min. 15, e máx. 180. Empresas de cortesia tem esse valor fixo em 15. Para produção, recomendamos manter em 90 pois em alguns tribunais pode haver um atraso entre a distribuição e a disponibilização no site ou na captura, fazendo com que algumas distribuições não sejam consideradas;
• inferior à data de hoje;
• superior à data da criação da parte monitorada.

Andamentos

O início do monitoramento por andamentos dos processos registrados começa a ocorrer em até 48h após o registro.

Publicações

Para as publicações em diários oficiais, o início do monitoramento começa a ocorrer em até 48h após o registro da parte monitorada ou processo. Os diários oficiais fazem suas publicações em horários diversos ao longo do dia, normalmente pela manhã. Enviamos os resultados em média 4h após a disponibilização dos diários no site do tribunal.

Frequência de envio de resultados via email

O envio de resultados via e-mail é feito toda manhã, de segunda a sexta, começando às 07:30 horário de Brasilia.

Frequência de envio de resultados via webhook

O envio de resultados via webhook (chamada HTTP da Digesto para o sistema do cliente) é feito 24/7, todos os dias do ano.

Enviado as novidades obtidas por nossos robôs assim que o dado é coletado e processado.

Fazemos as chamadas ao endereço HTTP informado pelo usuário em janelas de 3 minutos, sempre que tivermos novidades para enviar.

Movimentações processuais

As novas movimentações detectadas nos processos monitorados são enviadas via chamada webhook diariamente às 8:00 horário de Brasília. Esta chamada contém apenas as movimentações do dia anterior. Para os processos recem-registrados para monitoramento, enviamos na primeira chamada todas as movimentações conhecidas.

Novas distribuições

As novas distribuições (novos processos) detectadas envolvendo uma parte ou advogado monitorado são notificadas via webhook a cada duas horas.

Publicações

As novas publicações são obtidas tão logo os sites dos tribunais disponibilize os diários oficiais do dia corrente. Na média, em 45 minutos após a disponibilização dos diários oficiais fazemos o processamento do texto (separação em recortes e busca dos recortes que são de interesse das partes/processos monitorados na API). Após isso, fazemos o agendamento para envio dos resultados via webhook, que pode demorar até 15 minutos após a detecção do resultado.

Os horários (eixo-X, horário Brasilia) mais comuns para disponibilização dos eventos de publicações via nossa API são:

Falhas ao fazer envio dos resultados via webhook

O retorno do servidor HTTP remoto, incluindo o status HTTP é registrado para cada chamada que fazemos. As chamadas e retornos mais recentes podem ser consultados na página Configurações - Integração via API.

Uma chamada em que o servidor remoto retornar HTTP 200 em até 10 segundos é considerada bem sucedida. Qualquer código diferente ou dificuldade de conexão com o servidor remoto fará o envio ser retentado alguns minutos depois. Faremos até 13 re-tentativas. Cada retentativa é feita o dobro do tempo após o intervalo de espera da tentativa anterior. Ou seja, re-tentamos 2 minutos após a primeira falha, depois 4 minutos, 8, 16, 32… até a 13a tentativa, que ocorre 8192 minutos (5 dias) após a primeira tentativa. Este regime garante que os eventos são enviados mesmo que qualquer uma das partes fique indisponível por períodos longos de manutenção.

Registrando partes para monitoramento

O exemplo abaixo registra um nome (pessoa física ou jurídica) para monitoramento de novos processos judiciais distribuídos nos tribunais, especificando apenas o nome da parte. Veja também Detalhes de uma pessoa monitorada (/api/monitored_person).

Para monitorar por publicações em diários oficiais, basta modificar na chamada abaixo os atributos is_monitored_diario e is_monitored_tribunal.

Nota

Para monitorar partes que tenham mais de 450 novos processos nos últimos 15 dias, entre em contato conosco após o registro da parte. A API irá bloquear automaticamente partes com muitos resultados para evitar cadastros com erros (nomes homônimos muito comuns), partes com muitos processos que exijam planejamento de nossa infraestrutura etc. Também há um bloqueio para partes que possuem mais de 2048 variações de nome para a expressão regular entrada. Normalmente essa quantidade de variações significa que há algum erro na expressão usada.

Nota

Como alguns processos ficam visíveis no tribunal para consulta apenas alguns dias após a distribuição ou encontramos os dados deles alguns dias após sua distribuição, temos uma lógica que envia diariamente processos distribuídos ha até 90 dias atrás da data corrente. Só enviamos também processos distribuídos após a data da criação da parte monitorada. Note porém que, se uma parte tiver seu monitoramento desativado (ou for excluída) e depois for reativada, ou se for adicionado novo tribunal aos filtros, então enviaremos resultados retroativos. Ou seja, que não havíamos enviado enquanto o monitoramento estava desativado. Caso não deseje receber resultados retroativos após uma reativação, basta criar uma nova parte monitorada.

Nota

Seguimos a resolução 121/2010 da CNJ, a qual não permite buscar processos trabalhistas pelo nome do autor. Então se a parte monitorada aparecer no polo ativo de um processo trabalhista, não enviaremos o resultado.

Nota

Não enviaremos o processo como resultado da distribuição se: (a) o processo esteve sob segredo de justiça na época em que foi consultado por nossos robôs pela primeira vez ou em qualquer momento subsequente; ou (b) se o tribunal não informa as partes.

POST https://op.digesto.com.br/api/monitored_person

Exemplo de chamada:

POST https://op.digesto.com.br/api/monitored_person HTTP/1.1
Content-Type: application/json

{
  "nome": "Novo nome monitorado",
  "is_monitored_diario": false,
  "is_monitored_tribunal": true
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

{
    "$uri": "/api/monitored_person/18",
    "allow_many_procs": false,
    "cnpj": null,
    "cpf": null,
    "created_at": {
        "$date": 1467138337000
    },
    "disabled_too_many_procs": false,
    "is_active": true,
    "is_advogado": false,
    "is_monitored_diario": false,
    "is_monitored_tribunal": true,
    "is_archived": false,
    "last_search_finished_at": null,
    "manual_rex": false,
    "nome": "Novo nome monitorado",
    "nrex": null,
    "oab": null,
    "parteIDs": null,
    "parteIDs_last_update": null,
    "rex": null,
    "tribunaisIDs": [],
    "user_company": {
        "$ref": "/api/user_company/1"
    },
    "user_creator": null,
    "user_custom": null
}

Request Headers:  

• Authorization – token da API. Ver Autenticação.

Response Headers:  

• Content-Type – application/json

Status Codes:

• 200 OK – Sucesso

Detalhes de uma pessoa monitorada (/api/monitored_person)

Pode representar tanto um advogado, quanto uma pessoa física ou jurídica. Usado para monitoramento tanto em diários oficiais quanto para distribuições de novos processos.

É representado por um dicionário JSON com os seguintes campos.

created_at

[date] Quando a parte foi criada. Data em formato inteiro (JSON) (Formato de datas).

is_active

[boolean] Se o monitoramento desta parte está ativo. (default true).

is_advogado

[boolean] Se esta pessoa é um advogado. (default false).

is_monitored_tribunal

[boolean] Se o nome é monitorado por distribuições no tribunal (default true).

is_monitored_diario

[boolean] Se o nome é monitorado por publicações em diários oficiais (default false).

is_monitored_anexos

[boolean] Se o nome é monitorado com entrega de anexos (default false).

manual_rex

[boolean] Se campos rex e nrex foram editados e não devem ser reescritos.

nome

[string] Usado para encontrar processos e publicações desta parte. Nome da parte. Também usado para buscas nos tribunais que permitam busca direta. Deve ser por exemplo a razão social de uma empresa.

oab

[string, null] Usado para encontrar processos e publicações deste advogado. Deve estar no formato UF999999 (duas letras para UF e seis dígitos para número). Exemplo: RS005490 (não utilize espaços). Sufixos (D, E, N etc) são ignorados.

rex

[string, null] Usado para encontrar processos e publicações desta parte. Expressão regular usada para encontrar processos desta parte. Case insensitive. Não inclua acentos e cedilha na expressão regular. Caso um valor não seja informado, criaremos uma expressão conservadora automaticamente, baseada no campo nome. Ver a sintaxe aceita.

nrex

[string, null] Expressão regular negativa para encontrar processos desta parte. Em complemento ao campo rex, vamos ignorar todas as partes que derem match para esta expressão.

assunto_rex

[string, null] Considera apenas processos com assunto com essa expressão regular.

natureza_rex

[string, null] Considera apenas processos com natureza com essa expressão regular.

relacao_rex

[string, null] Considera apenas processos onde parte tem essa relação no processo.

comarca_rex

[string, null] Considera apenas processos em comarca com esta expressão regular.

partes_rex

[string, null] Considera apenas processos onde qualquer uma das outras partes do processo também dá match nesta expressão regular. Se o valor do campo começa com - então nenhuma parte pode dar match para a expressão regular entrada.

diarios_ids

[array of integer] Usado para encontrar publicações desta parte. Serve como filtro. Lista de identificadores de Diários Oficiais que devem ser considerados para recortes em publicações de diários oficiais da justiça. Ver Listando as fontes de Diário Oficial para pegar a lista completa de IDs dos diários monitorados por recortes. Para considerar todos os diários, passe um array vazio.

tribunaisIDs

[array of integer, null] Usado para encontrar novos processos distribuídos envolvendo esta parte. Serve como filtro. Lista de identificadores de tribunais que devem ser considerados para monitoramento de distribuições.

Dessa forma é possível selecionar tribunais de determinados estados ou de determinadas áreas jurídicas (trabalhista, civel).

A lista completa de IDs de tribunais pode ser obtida em Lista de IDs de Tribunais da base judicial Digesto.

Para considerar todos os tribunais, passe um array vazio.

filter_polo

[integer, null] Usado para encontrar processos desta parte. Papel da parte no processo: 0: polo qualquer (default); 1: autor; 2: co-autor 3: réu; 4: neutro.

dist_back_days

[integer] Usado para encontrar processos desta parte. Apenas Digesto pode modificar. Quantidade retroativa de dias usado no envio das distribuições (min 15, max 180, default 90). Empresas de cortesia tem esse valor fixo em 15. Para produção, recomendamos manter em 90 pois em alguns tribunais pode haver um atraso entre a distribuição e a disponibilização no site ou na captura, fazendo com que algumas distribuições não sejam consideradas. A configuração de data absoluta mínima das distribuições (para a empresa toda ou para uma parte monitorada específica) tem prioridade sobre esta configuração de dias retroativos.

user_custom

[string, null] Campo livre para uso do sistema integrado à API. Util para IDs internos. Até 256 caracteres.

distribuido_from

[date] Usado para encontrar processos desta parte. Considerar apenas processos distribuídos após esta data. Data em formato inteiro (JSON) (Formato de datas).

filter_instancias

[array of integer, null] Usado para guardar as instâncias de interesse no monitoramento, quando não fornecido o padrão é mandarmos apenas processos de primeira instância(1). Ver Instâncias de processos suportadas.

Nota

O campo is_monitored_anexos é false por padrão devido ao custo adicional do monitoramento de anexos. É necessário conferir se a empresa possue o módulo “(API) Monitorar distribuições” habilitado, para poder solicitar esse monitoramento.

Registrando processos para monitoramento

Para registrar novo processo para monitoramento, basta fazer um POST de um JSON com schema Detalhes de um processo monitorado (/api/proc).

Ao cadastrar um novo processo, o primeiro evento gerado possui todos os movimentos conhecidos do processo que ocorreram nos últimas 15 dias. No dia seguinte passamos a enviar só os novos movimentos. Este é o comportamento default. Este comportamento pode ser modificado para enviarmos todos os movimentos desde o início do processo, alterando o atributo JSON "all_movs_on_first_day": false do campo trib_monitor_config de uma user_company.

O início do envio de movimentos de um processo começa a ocorrer apenas 48h após o registro do processo e somente após o processo ter sido consultado uma primeira vez com sucesso no tribunal.

O monitoramento de processos e incidentes em todas instâncias é suportado, desde que o processo seja identificado e consultável no tribunal com o exato número padrão CNJ informado e que ao registrar o monitoramento, seja informado a instância no campo instancia. Ver Instâncias de processos suportadas.

Para solicitar o desmonitoramento de processos, veja Como remover o monitoramento de um processo?.

POST https://op.digesto.com.br/api/proc

O exemplo abaixo registra um processo para monitoramento com o mínimo de campos necessários. Neste exemplo o monitoramento do processo está habilitado tanto para novas movimentações nos tribunais, quanto novas publicações.

Exemplo de chamada:

POST https://op.digesto.com.br/api/proc HTTP/1.1
Content-Type: application/json

{
  "numero": "0283189-64.2012.8.19.0001",
  "is_monitored_diario": true,
  "is_monitored_tribunal": true
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

{
    "$uri": "/api/proc/10",
    "alias": null,
    "citado_at": null,
    "comment": null,
    "created_at": {
        "$date": 1463501760000
    },
    "distribuido_at": null,
    "editing_started_at": null,
    "instancia": 1,
    "is_archived": false,
    "is_digital": false,
    "is_editing": false,
    "is_extinto": false,
    "is_monitored_diario": true,
    "is_monitored_tribunal": true,
    "last_movimento_at": null,
    "last_updated_at": null,
    "numero": "1040985-29.2016.8.26.0100",
    "orgao": null,
    "processo_id": null,
    "source": 0,
    "status_monitor": 0,
    "summary": null,
    "procset": {
       "$ref": "/api/proc_set/2"
     },
    "uf": null,
    "user_company": {
        "$ref": "/api/user_company/1"
    },
    "user_creator": {
        "$ref": "/api/user/1"
    },
    "user_custom": null,
    "user_editor": null
}

Query Parameters:  

• id_update_callback (string) – Se um valor for passado, a API irá gerar um evento de monitoramento de tipo 13, com os dados completos do processo assim que ele for atualizado no tribunal. O valor passado neste argumento será informado no campo source_user_custom do evento.

Status Codes:

• 200 OK – registrado com sucesso

O exemplo abaixo registra um processo para monitoramento numa pasta (proc_set) de ID 1234.

Exemplo de chamada:

POST https://op.digesto.com.br/api/proc HTTP/1.1
Content-Type: application/json

{
    "numero": "0283189-64.2012.8.19.0001"
    "procset": 1234
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

{
    "$uri": "/api/proc/11",
    "alias": null,
    "citado_at": null,
    "comment": null,
    "created_at": {
        "$date": 1478893932000
    },
    "dias_sem_andamento": null,
    "distribuido_at": null,
    "editing_started_at": null,
    "encerrado_at": null,
    "fase": null,
    "instancia": 1,
    "is_archived": false,
    "is_digital": false,
    "is_editing": false,
    "is_extinto": false,
    "is_monitored_diario": true,
    "is_monitored_tribunal": true,
    "is_monitored_tribunal_temporeal": false,
    "last_diff_checked_at": null,
    "last_modified_at": null,
    "last_movimento_at": null,
    "last_updated_at": null,
    "numero": "0283189-64.2012.8.19.0001",
    "orgao": null,
    "processo_id": null,
    "procset": {
        "$ref": "/api/proc_set/1234"
    },
    "sent_movs_first_day": false,
    "source": 0,
    "status_monitor": 0,
    "summary": null,
    "uf": null,
    "user_company": {
        "$ref": "/api/user_company/1"
    },
    "user_creator": {
        "$ref": "/api/user/1"
    },
    "user_custom": null,
    "user_editor": null
}

Por default todos os novos processos monitorados são criados dentro da pasta (proc_set) de nome “Geral”.

Detalhes de um processo monitorado (/api/proc)

Todo processo monitorado pertence a uma pasta (conjunto) de processos ( proc_set). Caso a pasta (procset_id) não seja fornecida no momento da criação, ele ficará na pasta de nome Geral. Esta associação é feita de forma automática.

É representado por um dicionário JSON com os seguintes campos.

instancia

[integer] Inteiro entre 0 e 5. Ver Instâncias de processos suportadas. Default 1. O valor 0 significa que o processo será consultado nas instâncias 1 e 2 (condições comerciais especiais se aplicam a estes casos.)

tribunal

[integer,null] Ver listar_tribunais.

archived_at

[datetime] se foi excluido (nullable=True). Caso entidate tenha sido excluída, este campo tem o valor da datahora da última exclusão. Caso não esteja excluído, o valor é null. Campo somente-leitura.

is_monitored_diario

[boolean,null] se o monitoramento por novas publicações em Diários Oficiais Judiciais está ativo. Default true.

is_monitored_tribunal

[boolean,null] se o monitoramento por novas movimentações em Tribunais está ativo. Default true.

is_monitored_children

[boolean,null] se processos filhos (incidentes e instâncias superiores) com a mesma numeração CNJ devem ser monitoradas automaticamente. Default true.

numero

[string] código CNJ ou número antigo (alternativo). Pontuação, espaços, traços não importam.

tipo_numero

[integer] indica o tipo de número entrado no campo numero. Ver Tipos de números de processos. Default = 5

monitor_period

[integer] quando o processo é monitorado em tribunal, diz a frequencia de monitoramento: `1`=24h, `2`=48h, `3`=semana, `4`=4h, `5`= uma vez por mês, `6`= uma vez a cada dois meses (monitoramento feito sempre no início dos meses pares). Condições comerciais especiais se aplicam a cada uma das periodicidades.

processo_id

[integer,null] ID interno Digesto para este processo.

proc_set

[object] ref. para grupo de processos ao qual este monitoramento pertence.

user_custom

[string,null] valor livre para uso do sistema integrado à API. Usado para manter referências com identificadores do processo externos. Valor é enviado no campo source_user_custom dos eventos de monitoramento que originarem deste processo. Até 256 caracteres.

user_creator_id

[object] Usuário que criou o monitoramento.

Detalhes de um conjunto de processos monitorados (/api/proc_set)

É representado por um dicionário JSON com os seguintes campos.

Nome	Tipo	Descrição
$uri	string
created_at	object,null
archived_at	object,null
name	string
user_company	reference
user_creator	reference

Monitoramento de processos em 2ª instância

O registro de processos para monitoramento em 2ª instância é feito da mesma forma como os de 1ª.

Use a flag is_monitored_children para indicar se há interesse em monitorar processos filhos/relacionados (instâncias superiores e incidentes) a partir do CNJ informado. Esta flag tem o valor default true. Ou seja, por default o processo será monitorado em todas as instâncias.

Caso exista interesse explícito em monitorar apenas o número em 2ª instância, necessário escolher o parâmetro pelo campo instancia =2, conforme doc (Ver Instâncias de processos suportadas). O campo tipo_numero deve ser passado com o valor correspondente (ver Tipos de números de processos) ao número informado, e a flag is_monitored_children=false.

Por exemplo, você registra para monitoramento um processo 0009843-63.2016.8.13.0301 que hoje não está na 2ª instancia. Quando ele subir de instância, vamos detectar isso e o campo target_number de um evento de movimentação de processos indicaria que uma movimentação nova se refere a um recurso ordinário dele, por exemplo:

"target_number": "RO 0009843-63.2016.8.13.0301"

Ambiguidade ao registrar processo em 2ª instância

Ao fazer o registro de um processo, se houver ambiguidade com o mesmo número CNJ na 1ª e 2ª instância ou incidentes com o mesmo CNJ, e não for escolhido o monitoramento automático dos processos filhos, retornamos um código de erro HTTP 400 e uma lista de tuplas em JSON neste formato:

[número, tipo_numero, descricao]

Por exemplo:

{
    "message": [
        [
            300002083,
            7,
            "RTOrd 1000043-87.2015.5.02.0041"
        ],
        [
            300002085,
            7,
            "RO 1000043-87.2015.5.02.0041"
        ]
    ],
    "status": 400
}

Com estes números retornados, é necessário decidir entre: registrar para monitoramento algum número específico, ou reenviar a chamada com a flag is_monitored_children com valor true.

Listando processos monitorados

Pode ser feito listando entidades do tipo proc. Ver Listando recursos.

Tipos de números de processos

Sempre que o número de um processo precisa ser informado na API, há um campo para identificar qual o tipo de número. Este campo (tipo_numero) pode ter estes valores:

• 4 = Slug, ex.: rtsum-0011861-37-2017-5-03-0144
• 5 = CNJ, ex.: 0011861-37.2017.5.03.0144
• 7 = ID Digesto desse processo, ex.: 303723986
• 8 = ID Digesto ou CNJ desse processo, ex.: 0011861-37.2017.5.03.0144

Registrando palavras para monitoramento em Diários Oficiais

Uma expressão qualquer pode ser registrada para monitoramento em publicações de diários oficiais realizando um HTTP POST para o recurso da API monitored_term, com os detalhes da entidade abaixo.

O resultado deste monitoramento não vem estruturado como recorte (indicando qual o processo, qual o texto da movimentacao, quais as partes etc). Ele seria mais usado para monitorar nomes/marcas/produtos, projetos de lei etc em diários executivos.

Os resultados diários do monitoramento são enviados conforme Dados de um evento.

POST https://op.digesto.com.br/api/monitored_term

O exemplo abaixo registra a expressão “Termo procurado” para monitoramento contínuo nos diários oficiais de id 1, 2 e 3. E retorna a entidade monitored_term recém criada.

Exemplo de chamada:

POST https://op.digesto.com.br/api/monitored_term HTTP/1.1
Content-Type: application/json

{
    "sources": [
        1,
        2,
        3
    ],
    "term": "Termo procurado"
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

{
    "$uri": "/api/monitored_term/4",
    "archived_at": null,
    "created_at": {
        "$date": 1486228120000
    },
    "is_active": true,
    "is_reviewed": true,
    "nrex": null,
    "percolator_id": null,
    "rex": "Termo procurado",
    "sources": [
        1,
        2,
        3
    ],
    "term": "Termo procurado",
    "user_company": {
        "$ref": "/api/user_company/1"
    },
    "user_creator": {
        "$ref": "/api/user/1"
    },
    "user_creator_id": 1,
    "user_custom": null
}

Status Codes:

• 200 OK – registrado com sucesso

Detalhes de uma expressão monitorada (/api/monitored_term)

Representa uma expressão monitorada em diários oficiais. A expressão pode ser composta por uma ou mais palavras e expressões lógicas para excluir termos da busca.

É composto por um dicionário JSON com os seguintes campos.

Nome	Tipo	Descrição
$uri	string	ID interno Digesto
created_at	object,null	Quando a entidade foi criada
is_active	boolean	Se o monitoramento está ativo.
archived_at	object,null	Se foi excluido (nullable=True). Caso entidate tenha sido excluída, este campo tem um objeto contendo o valor da datahora da última exclusão. Caso não esteja excluído, o valor é null. Campo somente-leitura.
is_reviewed	boolean, default: false	Se já foi revisado pela equipe Digesto
term [1]	string	Texto a ser buscado. Expressão lógica usando a sintaxe Lucene <https://lucene.apache.org/core/2_9_4/queryparsersyntax.html>.
sources	array,null	Array de inteiros. Lista de ids de cadernos de diários oficiais a serem monitorados. Ver Listando as fontes de Diário Oficial para pegar a lista completa.
user_company	object	Referência à empresa à qual o pedido pertence. (“UserCompany”). Campo somente-leitura, preenchido automaticamente na criação.
user_creator	object	Usuário que criou esta pessoa monitorada
user_custom	string,null	Campos livre para uso do sistema integrado à API. Util para IDs internos

[1]	Obrigatório na criação de entidades.

Listar todas os IDs de partes ou expressões regulares de uma empresa

GET https://op.digesto.com.br/api/user_company/(int: id)/all_parte_ids

Retorna lista com IDs de partes monitoradas da empresa passada (via id da user_company na URL). Opcionalmente retorna as expressões regulares.

Exemplo de chamada:

GET https://op.digesto.com.br/api/user_company/111/all_parte_ids?regexps=true HTTP/1.1
Accept: application/json

Exemplo de resposta:

HTTP/1.1 200 OK
Content-Type: application/json

[
  "\bA ?S ?B\b.{0,30}\bBEB.{0,5}\b.{0,30}\bALIM",
  "\b(N|M)ESTLE\b.{0,30}\b(W|V)ATERS?\b.{0,30}\bBR.{0,4}\b.",
  "\b(N|M)ESTLE\b.{0,30}\bBR.{0,4}\b",
  "\bFRO(N|M)ERI\b.{0,30}\bBR.{0,4}\b"
]

Query Parameters:  

• regexps (boolean) – Default é false. Caso valor seja true, retorna uma lista com a expressão regular de cada parte monitorada, ao invés dos IDs de partes Digesto.

Solicitar renovação da validade de URLs de anexos

Aviso

O uso desta API é experimental e pode sofrer restrições de chamadas ou mudanças no funcionamento. Daremos aviso prévio de 15 dias em caso de alterações.

POST https://op.digesto.com.br/api/monitored_event/renew_gcs_lease

Solicita a geração de nova URL para download de um anexo passado como parâmetro. A nova URL é devolvida na resposta, e tem validade de 15 dias. Este método aceita apenas URLs geradas pelo Digesto, e que possuam o prefixo https://storage.googleapis.com/.

Exemplo de chamada:

POST https://op.digesto.com.br/api/monitored_event/renew_gcs_lease HTTP/1.1
Content-Type: application/json

{
    "url": "https://storage.googleapis.com/dg-diario-split/split-do-al-alagoas-completo-2020-06-03-64.pdf?Expires=1622754130&GoogleAccessId=agentebrasildiario%40appspot.gserviceaccount.com&Signature=q9ah6nQ9vPoo8Md1H0CMZI%2Ft6WuAVyjJPdP...dYh07g%3D%3D"
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

"https://storage.googleapis.com/dg-diario-split/split-do-al-alagoas-completo-2020-06-03-64.pdf?Expires=1598708722&GoogleAccessId=dg-op-web%40digestojud.iam.gserviceaccount.com&Signature=VOvK...qgk3LA%2F0OBFzw%3D%3D"

Request Headers:  

• Authorization – token da API. Ver Autenticação.

Response Headers:  

• Content-Type – application/json

Request JSON Object:  

• url (string) – URL do anexo enviado anteriormente por alguma API Digesto.

Status Codes:

• 200 OK – Sucesso

Obter variações de nomes para parte monitorada

Aviso

Deprecado. Esse endpoint não deve mais ser usado, consulte a seção: Obter variações de nomes para parte monitorada na base 2.

É possível seguindo esses passos.

HTTP GET para os detalhes da parte monitorada:

HTTP GET https://op.digesto.com.br/api/monitored_person/38116

que retorna um json com um campo “parteIDs” que é uma lista de inteiros. Pega então essa lista e faz uma segunda chamada passando esses IDs:

HTTP POST para https://op.digesto.com.br/api/tribproc/partes_for_ids

Com o conteúdo JSON no corpo do request:

{
  "i": 0,
  "ids": [
    8204419,
    6451124
  ]
}

o retorno dessa chamada é

{
  "i": 0,
  "nomes": [
    [
      6451124,
      "Paulo Valinas Carpintero Villaverde",
      "PAULO VALINAS CARPINTERO VILLAVERDE",
      null,
      null,
      null
    ],
    [
      8204419,
      "PAULO VALIÑAS CARPINETRO VILLAVERDE",
      "PAULO VALINAS CARPINETRO VILLAVERDE",
      null,
      null,
      null
    ]
  ]
}

Obter variações de nomes para parte monitorada na base 2

Colete os ids das variações da parte monitorada na coluna ator_ids e foneça esses IDs na chamada para o endpoint atores_for_ids.

GET https://op.digesto.com.br/api/monitored_person/37101

Exemplo de resposta

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

{
    "$uri": "/api/monitored_person/37101",
    "allow_many_procs": false,
    "archived_at": {
        "$date": 1542652792000
    },
    "assunto_ids": [],
    "assunto_ids_last_update": null,
    "assunto_nrex": null,
    "assunto_rex": null,
    "ator_ids": [
        26509492,
        7835996,
        27904007,
        28340780
    ],
    "ator_ids_last_update": {
        "$date": 1541220467000
    },
    "ator_ids_removed": null,
    "cnpj": null,
    "comarca_ids": [],
    "comarca_ids_last_update": null,
    "comarca_rex": null,
    "cpf": null,
    "created_at": {
        "$date": 1539613127000
    },
    "diarios_ids": [],
    "disabled_too_many_parteids": false,
    "disabled_too_many_procs": false,
    "dist_back_days": 30,
    "distribuido_from": null,
    "filter_instancias": [
        1
    ],
    "filter_polo": 0,
    "is_active": true,
    "is_advogado": false,
    "is_disabled_trial": false,
    "is_filter_rex_reus": false,
    "is_monitored_anexos": false,
    "is_monitored_diario": false,
    "is_monitored_tribunal": true,
    "is_trial": false,
    "last_search_finished_at": {
        "$date": 1542644997000
    },
    "manual_rex": true,
    "natureza_ids": [],
    "natureza_ids_last_update": null,
    "natureza_nrex": null,
    "natureza_rex": null,
    "nome": "Banco Volkswagen",
    "nrex": "",
    "oab": null,
    "parteIDs": [
        41889793,
        52848642,
        12568582,
        11024391,
        56209422,
        52848655,
    ],
    "parteIDs_last_update": {
        "$date": 1542478233000
    },
    "parte_ids_removed": null,
    "partes_rex": null,
    "relacao_ids": [],
    "relacao_ids_last_update": null,
    "relacao_rex": null,
    "rex": "\\bBANCO\\b.{0,20}\\b[WV]OL[CK]S[WV]AGE[MN]\\b",
    "rex_reviewed_at": {
        "$date": 1539992191000
    },
    "tribunaisIDs": [],
    "user_company": {
        "$ref": "/api/user_company/4"
    },
    "user_company_id": 4,
    "user_creator": {
        "$ref": "/api/user/2879"
    },
    "user_creator_id": 2879,
    "user_custom": null,
    "valor_exato_proc": []
}

POST https://op.digesto.com.br/api/tribproc/atores_for_ids

Solicita o nome e os documentos de partes da base judicial.

Exemplo de chamada

POST https://op.digesto.com.br/api/tribproc/atores_for_ids HTTP/1.1
Content-Type: application/json

{
    "ator_ids": [
      26509492,
      7835996,
      27904007
  ]
}

Exemplo de resposta:

HTTP/1.1 200 OK
Vary: Accept
Content-Type: application/json

[
    {
        "cnpj": null,
        "cpf": null,
        "documento": null,
        "nomeParte": "Banco  Volkswagen Consorcios",
        "nomeParteNormalizado": "BANCO VOLKSWAGEN CONSORCIOS"
    },
    {
        "cnpj": null,
        "cpf": null,
        "documento": null,
        "nomeParte": "BANCO VOLKSVAGEN S/A - (CURITIBA)",
        "nomeParteNormalizado": "BANCO VOLKSVAGEN S A - CURITIBA"
    },
    {
        "cnpj": null,
        "cpf": null,
        "documento": null,
        "nomeParte": "BANCO VOLKSWAGEN S/A (R.MARECHAL DEODORO, 630/CTBA",
        "nomeParteNormalizado": "BANCO VOLKSWAGEN S A R MARECHAL DEODORO 630 CTBA"
    }
]

Request Headers:  

• Authorization – token da API. Ver Autenticação.

Response Headers:  

• Content-Type – application/json

Request JSON Object:  

• ator_ids (array) – lista com os ids das variações da parte.

Status Codes:

• 200 OK – Sucesso