Monitor de Marcas INPI — Alertas da RPI por Processo

Vigia processos de marca no INPI e avisa só quando sai um despacho novo — sem você abrir a RPI toda semana pra conferir na mão.

Overview

Duas informações que a RPI publica em cada edição — número de processo e nome do titular — são a chave de tudo aqui. O actor baixa a edição indicada, casa contra a sua lista de vigilância e compara com o histórico da execução anterior. O que já apareceu numa edição passada não volta a ser reportado; só o despacho genuinamente novo entra no dataset.

CNPJ não é campo estruturado nos dados da RPI — o INPI publica nome/razão social do titular, não o documento. Por isso a vigilância aqui é por número de processo (exato) ou por nome de titular (substring, case-insensitive), nunca por CNPJ.

Features

• Vigilância por número de processo (casamento exato) ou por nome/razão social de titular (substring).
• Delta real entre execuções: histórico de despachos já vistos persiste num key-value store nomeado, isolado por watch-config.
• Lista de códigos de despacho (IPAS) relevantes é configurável — o padrão cobre os 12 códigos mais frequentes (concessão, indeferimento, exigência, oposição etc.), mas você decide o que dispara alerta.
• Processa uma ou várias edições da RPI numa única execução, sempre da mais antiga pra mais nova, pra o delta fechar certo.
• Edição ainda não publicada ou inexistente não derruba a execução — ela é pulada com aviso, o resto continua.
• Baseline automático na primeira execução de cada watch-config: nada "nasce" como alerta falso.

Input example

{
  "watchProcessos": ["936582294"],
  "watchTitulares": ["Renova Ltda"],
  "relevantCodes": ["IPAS029", "IPAS158", "IPAS270"],
  "edicoes": [2896],
  "stateStoreName": "minha-carteira-de-marcas"
}

Output example

Saída real de uma execução de teste (edição 2896, processo 936582294):

{
  "numero_processo": "936582294",
  "titular": "RENOVA LTDA EPP",
  "codigo_despacho": "IPAS158",
  "descricao_despacho": "Concessão de registro",
  "classe_nice": ["38"],
  "edicao_rpi": 2896,
  "data_edicao": "07/07/2026",
  "detectado_em": "2026-07-11T02:05:02.707Z"
}

Quando não há despacho novo relevante para nenhum processo vigiado, o dataset volta vazio — é a resposta esperada, não uma falha (ver FAQ).

Tabela de parâmetros

Campo	Tipo	Obrigatório	Descrição
watchProcessos	array de string	Não*	Números de processo a vigiar. Casamento exato.
watchTitulares	array de string	Não*	Nomes/razão social a vigiar. Casamento por substring, case-insensitive.
relevantCodes	array de string	Não	Códigos IPAS que geram alerta. Vazio ou omitido cai no padrão de 12 códigos mais frequentes.
edicoes	array de número	Sim	Números das edições da RPI a processar (ex.: [2896]). Esta versão exige edição explícita.
stateStoreName	string	Não	Nome do key-value store de histórico. Em branco, é derivado automaticamente da watch-config (mesma config sempre cai no mesmo store; configs diferentes ficam isoladas).

* Ao menos um de watchProcessos ou watchTitulares deve estar preenchido, senão nenhum processo é vigiado e a execução não emite nada.

Tips

• Descubra o número da edição atual na página oficial da RPI antes de rodar — esta versão não resolve "a última edição" sozinha.
• Rode agendado (schedule semanal, terça-feira costuma ser dia de publicação) com o mesmo stateStoreName fixo pra manter o delta persistindo.
• Se watchTitulares casar centenas de processos numa edição, o log avisa — normalmente sinal de que o termo está genérico demais (ex.: uma palavra comum isolada).
• Trocar watchProcessos, watchTitulares ou relevantCodes muda o hash do store derivado e gera um novo baseline — o histórico antigo não some, só para de ser consultado.

Use cases

• Escritório de marcas monitorando a carteira de clientes: um stateStoreName por cliente, alerta automático de exigência ou oposição.
• Empresa vigiando a própria marca: saber no dia em que sai concessão, prorrogação ou qualquer despacho crítico, sem depender de aviso do INPI por e-mail.
• Vigilância concorrencial por titular: acompanhar os depósitos e despachos de um concorrente específico pelo nome.
• Escritório jurídico com prazo processual: despacho que abre prazo de manifestação (oposição, exigência) vira gatilho de tarefa no mesmo dia da publicação.
• Auditoria de portfólio de marcas: rodar contra toda a lista de processos da empresa a cada edição pra garantir que nada passou batido.
• Integração com CRM/ticketing: o dataset por evento alimenta direto um webhook ou automação (Zapier/Make) que abre um ticket a cada despacho novo.

FAQ

Por que não posso vigiar por CNPJ? Porque a RPI não publica CNPJ estruturado — só nome/razão social do titular. Vigie por nome (substring) ou pelo número do processo, que é exato.

O dataset veio vazio, algo quebrou? Não necessariamente. Dataset vazio é a resposta correta quando nenhum despacho novo relevante saiu pros processos/titulares vigiados naquela(s) edição(ões). "Sem novidade" é um resultado válido.

Preciso informar edicoes toda vez? Sim, nesta versão. Resolução automática da "última edição publicada" não está implementada — confira o número atual na RPI antes de rodar.

Uma edição errada ou ainda não publicada derruba a execução? Não. A edição inválida é pulada com aviso no log (edicoes_falharam no resumo final) e o restante processa normalmente.

O que acontece se eu mudar relevantCodes depois de já ter rodado? Despachos já vistos continuam no histórico independente do código — só o filtro de EMISSÃO muda. Um código que passou a ser relevante não vai "reaparecer" retroativamente se já tinha sido visto antes com outro filtro; só despachos novos dali pra frente respeitam a lista atualizada.

Por que dois eventos de cobrança (execução e despacho) em vez de um só por item do dataset? Baixar e processar uma edição tem custo fixo (arquivo de dezenas de MB, dezenas de milhares de processos), independente de quantos despachos batem no seu watch. Cobrar só por item deixaria watchlists pequenas rodando no prejuízo. O evento de execução cobre esse custo fixo; o evento por despacho paga o sinal.

Pricing

Modelo pague-por-evento (PPE), dois eventos:

Evento	Preço
Execução do monitor (monitor_run) — 1x por execução, cobre qualquer edição processada	US$ 0,10
Despacho novo detectado (despacho_detected) — 1x por item emitido no dataset	US$ 0,50

Exemplo de custo real: vigiar 1 processo contra 1 edição com 1 despacho novo relevante = US$ 0,10 (execução) + US$ 0,50 (despacho) = US$ 0,60. Rodar contra uma edição sem nenhum despacho novo pros seus processos vigiados custa só os US$ 0,10 da execução — dataset vazio não é bug, é o resultado honesto de "nada mudou" (ver FAQ). A primeira execução de cada watch-config sempre estabelece o baseline: despachos já existentes na primeira leitura viram histórico, não alerta — você não paga por "descobrir" o passado inteiro do processo de uma vez.

Related Actors

Parte da suíte de dados e compliance de empresas brasileiras:

• Consulta CNPJ em Lote — dados cadastrais da Receita Federal.
• Certidões de Regularidade BR — FGTS e trabalhista por CNPJ.
• Monitor ESG BR por CNPJ — Lista Suja do trabalho escravo + autos IBAMA.
• Precatórios TJSP — fila de pagamento por entidade.
• Consulta de Protesto SP — CENPROT por CPF/CNPJ.

Changelog

• v0.0 (11/07/2026): primeira versão. Vigilância por processo/titular, delta com baseline automático, cobrança PPE por execução + por despacho detectado, edições inválidas não derrubam a execução.

Contato

Dúvida, sugestão de campo novo ou código IPAS que falta na lista padrão: abra uma issue direto na página do Actor no Apify Store ou mande mensagem pelo perfil paulovitor18.