Referência: Início rápido da API
A n8n é uma plataforma de automação de fluxos, e desde 1º de maio de 2026 um nó
comunitário que queira o selo de verificado dela vive sob três regras. Tem de
ser publicado por GitHub Actions com proveniência, isto é, com um comprovante
assinado de qual código virou aquele pacote. Não pode tocar em arquivo nem em
variável de ambiente. E tem de passar limpo pelo
@n8n/scan-community-package. Eu cheguei nessas regras querendo
reclamar e saí concordando com todas. Cada proibição forçou uma decisão que eu
deveria ter tomado de qualquer jeito.
Sem filesystem: o documento é binary data ou não é nada
A proibição de tocar arquivos elimina a tentação mais comum desse tipo de integração: receber um caminho e ler do disco.
No n8n, o documento chega ao nó como binary data do item anterior, que pode ser um anexo de e-mail do gatilho IMAP ou um upload de webhook. E sai do mesmo jeito: os bytes vão para a API, o relatório volta como JSON, nada é gravado em lugar nenhum.
O servidor da Tamperlens processa em memória e descarta com a resposta. O nó não persiste nada por conta própria. Então a pergunta "onde o documento ficou salvo?" tem a melhor resposta possível: em lugar nenhum.
O contraste com o nosso próprio servidor MCP é instrutivo. O MCP roda na máquina de quem o instala e lê caminhos locais de propósito. A fronteira de confiança está documentada em letras garrafais: só use com agentes e entradas confiáveis.
São dois modelos de confiança diferentes porque os hosts são diferentes. E a regra da n8n acerta para o caso dela: um nó instalado num n8n multiusuário não tem nada que ler o disco do servidor.
Três operações, medição declarada
| operação | o que faz | custo |
|---|---|---|
| Inspect Document | inspeção estrutural completa de PDF, imagem ou arquivo Office; devolve banda de risco e a lista de sinais com evidência | 1 doc |
| Get Metadata | os metadados que o arquivo carrega, sem inspeção completa | 1 doc |
| Compare Documents | o candidato contra o original que você já confia, dois campos binários | 2 docs |
Dois detalhes que só aparecem quando alguém opera isso de verdade.
O teste de credencial chama um endpoint autenticado que não é medido. Testar a conexão nunca gasta quota, então ninguém precisa escolher entre validar a chave e economizar documento.
E o pacote tem zero dependências de runtime, o que não é virtude estética. Cada dependência de um nó comunitário roda dentro do n8n de quem instalou. A lista vazia é a resposta mais curta possível à pergunta de segurança que a verificação existe para fazer.
O fluxo típico é o da capa. Um gatilho entrega o documento, o nó inspeciona,
e um IF roteia por riskBand, que é a banda de risco do
relatório. Banda baixa segue sozinha, e o resto vai para uma fila humana com
os sinais anexados como evidência para o revisor. Quem quer granularidade
roteia por signals[].id, que são identificadores estáveis de
família, em vez de usar só a nota.
O estado honesto das coisas
O pacote está no npm desde 11 de agosto e a submissão de verificação
está pendente do lado da n8n. Até o selo sair, a instalação é pelo
nome do pacote em Settings, Community Nodes:
n8n-nodes-tamperlens. E vale a mesma frase que o
relatório carrega em todo lugar: o nó devolve sinais de risco com
evidência, nunca um veredicto de autenticidade. Sinal tem causa
benigna; a decisão é do seu fluxo, e é bom que seja.
O início rápido da API mostra a mesma inspeção em um curl, sem conta nenhuma. A chave gratuita cobre 50 documentos por mês, o suficiente para provar o fluxo inteiro antes de pagar qualquer coisa.