Firecrawl no n8n: o atalho para agentes de IA sem manter crawler

Firecrawl coleta e normaliza conteúdo da web; o n8n decide quando buscar, validar e entregar esse conteúdo. Essa combinação faz sentido para quem precisa alimentar RAG ou agentes de IA sem operar navegador, proxy, fila e parser. Ela não libera coleta sem permissão: URL, frequência, campos e destino continuam sob responsabilidade de quem monta o workflow.

Objetivo: configurar um fluxo mínimo que transforma uma URL permitida em Markdown para RAG ou um agente. Este guia sugere uma configuração baseada na documentação do Firecrawl; não é um teste reproduzido pelo Runzos. Tempo: não medido. Custo: o plano Free exibia US$0 e 1.000 créditos mensais em 22 de agosto de 2026. Pré-requisitos: conta, chave de API e acesso ao n8n.

Para um solo builder, o problema raramente é fazer uma requisição HTTP. O problema é manter essa requisição útil quando a página renderiza JavaScript, muda o HTML ou pede outra camada de operação.

O Firecrawl oferece API, SDKs, CLI e MCP. A API v2 do Firecrawl lista as operações disponíveis. O n8n entra como orquestrador: recebe um gatilho, aplica regras, grava o resultado e decide o que fazer quando algo falha. A página do Firecrawl no Runzos ajuda a contextualizar a ferramenta antes da configuração.

A nossa leitura é simples: o Firecrawl é bom quando extrair dados web atualizados apoia o seu produto, mas não é o seu produto. É a chamada Taxa de Operação Terceirizada: um custo recorrente para não manter browser, proxy, renderização, fila, retry e normalização por conta própria.

O que o Firecrawl resolve, e o que continua sendo seu

💡 Vai rodar n8n numa VPS? A gente comparou o preço real em cada provedor — com renovação e requisitos — em VPS para n8n.

A API v2 lista operações como Search, Scrape, Batch Scrape, Interact, Map, Parse, Crawl, Monitor e Agent. A escolha depende da pergunta que o workflow precisa responder, não de qual endpoint parece mais completo na documentação.

No serviço hospedado, o fornecedor descreve suporte a proxy rotativo, orquestração, rate limits e conteúdo renderizado por JavaScript. Isso reduz trabalho operacional. Não é uma garantia de que toda URL será acessível, nem uma autorização para ignorar robots.txt, termos de uso ou a LGPD.

O n8n continua responsável pelo que acontece antes e depois da coleta. É ele que deve limitar as URLs aceitas, impedir duplicações, registrar créditos usados, tratar erros e escolher se o conteúdo segue para um banco vetorial, uma revisão humana ou um agente.

Essa divisão é especialmente útil para quem já compara plataformas de automação. Se ainda estiver escolhendo a camada de workflow, vale consultar n8n vs Make em 2026. O ponto aqui não é substituir o n8n. É dar a ele uma fonte de dados web mais estruturada.

Pré-requisitos da configuração

Antes de montar o fluxo, tenha uma conta Firecrawl, uma chave de API criada no painel e acesso a uma instância n8n Cloud ou self-hosted. Também escolha uma URL pública e permitida para a primeira configuração. Não use URL privada, dados pessoais ou página sem relação com o seu caso de uso.

Você precisa de um destino para o Markdown, mesmo que seja apenas uma execução de teste no n8n. Para RAG, planeje onde guardar URL de origem, data de coleta e conteúdo. Para um agente, defina quais domínios ele pode consultar antes de dar acesso à ferramenta.

Etapa 1: crie a chave e defina uma lista permitida

Comece criando a chave de API no Firecrawl e guarde-a como credencial ou variável secreta no n8n. A chave não deve aparecer em nó Set, print de execução, URL compartilhada ou captura de tela.

A documentação do MCP oficial também orienta manter a chave em armazenamento de segredos ou variável, e não na URL. Mesmo que você use o Firecrawl via MCP em um agente, a regra de segredo é a mesma.

Depois, crie uma lista permitida de domínios ou URLs. Esse controle parece burocrático até o dia em que um formulário, uma URL arbitrária ou um prompt injeta uma página que seu processo não deveria coletar.

Use uma política simples antes de ativar o fluxo:

1. Aceite apenas domínios que façam sentido para o caso de uso.
2. Defina quais campos serão extraídos e por quanto tempo serão guardados.
3. Limite o número de URLs por execução.
4. Registre falhas e créditos usados por workflow.
5. Revise se há dados pessoais, termos de uso ou finalidade incompatível.

Ter crédito para consultar uma página não resolve a questão da permissão para usar seus dados. O workflow precisa de finalidade e minimização, principalmente quando o resultado pode virar contexto de um agente comercial.

Etapa 2: faça Scrape no n8n para transformar URL em Markdown

A integração oficial do Firecrawl para n8n cobre operações do produto. Para uma operação ainda não exposta pelo nó instalado, a orientação oficial é usar um HTTP Request. Isso é útil porque evita depender da versão de um nó comunitário para acessar a API v2.

Um fluxo inicial pode ter seis etapas: Trigger, validação da URL, HTTP Request ou nó Firecrawl, validação da resposta, destino do conteúdo e ramo de erro. Não trate o primeiro retorno como dado pronto para RAG. Confira status, conteúdo vazio, formato e duplicidade antes de indexar.

Etapa 2.1: salve a credencial e o segredo

No n8n, salve a chave como credencial. No HTTP Request, referencie a credencial em vez de colar o token em texto aberto. Assim, exportar ou compartilhar o workflow não expõe a chave por acidente.

A API de Scrape usa Bearer token e recebe a URL. A documentação informa que o produto pode entregar formatos como Markdown, HTML, screenshot ou JSON estruturado, conforme a configuração. Para um primeiro pipeline de contexto, Markdown costuma ser uma saída direta para revisão e chunking posterior.

Etapa 2.2: escolha entre nó Firecrawl e HTTP Request

Use o nó Firecrawl quando a operação estiver disponível na versão que você instalou e a interface resolver o caso. Use HTTP Request quando precisar chamar um endpoint v2 sem esperar a atualização do nó.

A configuração abaixo é um ponto de partida baseado na referência da API. Ajuste os campos à versão exibida pela documentação antes de pôr em produção.

{
  "method": "POST",
  "url": "https://api.firecrawl.dev/v2/scrape",
  "headers": {
    "Authorization": "Bearer {{$credentials.firecrawlApiKey}}",
    "Content-Type": "application/json"
  },
  "body": {
    "url": "{{$json.url}}",
    "formats": ["markdown"]
  }
}

O campo {{$json.url}} deve vir de uma etapa anterior que valide domínio e formato. Não aceite uma URL fornecida diretamente por um chat ou webhook sem essa barreira.

Etapa 2.3: valide a resposta antes de enviá-la ao agente

Após o Scrape, passe por um nó IF ou Code que descarte respostas sem conteúdo útil. Também é uma boa hora para anexar metadados: URL de origem, horário da coleta, workflow que gerou o item e uma identificação do documento.

Para RAG, armazene a origem junto com o Markdown. Isso permite exibir a fonte depois e facilita substituir conteúdo desatualizado. Para um agente, prefira passar contexto pequeno e específico. Jogar um site inteiro no prompt não é uma estratégia de recuperação.

Como validar a configuração

Considere a configuração bem-sucedida quando uma URL da lista permitida retorna conteúdo não vazio no formato escolhido, com URL de origem registrada e sem expor a chave nos dados da execução. Considere falha quando a URL não passa pela validação, a API retorna erro, o conteúdo vem vazio ou o consumo de créditos excede o teto definido. Nesses casos, interrompa o ramo antes de indexar ou repassar dados ao agente.

Etapa 3: escolha o endpoint antes de criar o workflow

O erro comum é usar Crawl para tudo. O endpoint certo reduz etapas, crédito desperdiçado e lógica de pós-processamento.

O map descobre URLs em um site e aceita busca para encontrar páginas relevantes. É uma escolha melhor quando seu workflow começa por domínio e não por uma URL exata.

O search pode devolver resultados e conteúdo das páginas. Ele é útil quando a automação precisa localizar uma fonte antes de extrair. Já o crawl inicia um job e devolve identificador e URL de status. Por isso, ele pede um fluxo diferente do Scrape.

Etapa 4: trate Crawl como fluxo assíncrono com polling, retry e teto de gasto

Um Crawl não deve terminar em um único nó que presume sucesso. A documentação mostra o início do job, um ID e uma consulta posterior de status, incluindo creditsUsed no exemplo.

No n8n, crie um ramo que grave o ID do job. Depois, use espera e polling do status até a conclusão, falha ou prazo máximo. Em caso de falha transitória, aplique retry com limite. Em caso de conteúdo inválido, envie o item para revisão ou registre a URL para investigação.

Evite retries infinitos. Eles aumentam custo e escondem um problema de origem. Defina quantas tentativas uma URL merece e qual é o orçamento máximo por execução. Também separe erro da API, URL proibida e conteúdo vazio. Os três pedem decisões diferentes.

Problemas comuns na configuração e como agir

A chave aparece no histórico da execução

Pare o workflow compartilhado e mova a chave para uma credencial ou secret do n8n. Revogue a chave exposta e gere outra no Firecrawl. Não resolva isso apenas ocultando o valor em um nó depois da execução: exports e logs anteriores podem continuar acessíveis.

A URL é aceita, mas o conteúdo volta vazio

Não envie essa resposta para RAG ou agente. Registre a URL, o status e o formato solicitado; depois confira se o domínio está na lista permitida e se a operação escolhida é adequada. Uma página que exige interação pode pedir outro desenho de fluxo, mas isso não autoriza contornar termos, robots ou acesso restrito.

O Crawl fica em processamento ou consome mais créditos do que o teto

Use o ID do job para consultar o status em intervalos definidos e encerre o ramo ao atingir prazo, tentativas ou orçamento máximo. Verifique creditsUsed quando a resposta o disponibilizar. Não repita a mesma solicitação indefinidamente: a causa pode ser a URL, o payload ou um limite do serviço.

Etapa 5: entregue o resultado para RAG ou para um agente de IA

O objetivo não é transformar toda página em contexto permanente. O objetivo é levar informação rastreável para a etapa certa.

Em um RAG, o fluxo pode salvar Markdown, URL, data de coleta e um hash do conteúdo. Depois, uma etapa de chunking e embeddings indexa apenas material aprovado. Se a página muda, você substitui os chunks ligados à mesma origem.

Em um agente, o Firecrawl pode funcionar como ferramenta sob demanda. O MCP oficial aceita acesso sem chave dentro de limites diários, login ou API key. Ainda assim, deixe claro quais domínios o agente pode consultar e quais tipos de resposta ele pode repassar.

Se o agente precisar de um modelo, uma camada como OpenRouter pode entrar na arquitetura. Mas ele não substitui a governança da coleta. Modelo, automação e fonte de dados são responsabilidades separadas.

Etapa 6: estime o custo antes de rodar uma automação pequena

A tabela de preços do Firecrawl, capturada em 22 de agosto de 2026, mostra plano Free com 1.000 créditos por mês, sem custo, duas requisições concorrentes e limites de taxa baixos. Para testar um fluxo real com páginas simples, essa é a referência mais segura.

A mesma tabela mostra que Scrape, Crawl e Map usam um crédito por página. Search custa dois créditos por dez resultados. Interact custa dois créditos por browser-minute. Monitor cobra um crédito por página e por verificação. Agent Preview tem cinco execuções diárias gratuitas e preço dinâmico.

Esses valores foram capturados em 22 de agosto de 2026 e são exibidos para cobrança anual. A fatura é em dólar. O custo final em reais depende de câmbio, IOF e emissor do cartão, então não faz sentido prometer uma conversão fixa neste artigo.

Para uma conta simples, use a conta de páginas: páginas simples multiplicadas por um crédito. Não estenda essa conta para Search, Interact ou Agent, porque esses recursos têm outra regra de consumo.

Quando Firecrawl vale mais que manter crawler próprio

A Taxa de Operação Terceirizada vale quando seu diferencial está em analisar, recomendar ou automatizar com o dado, não em derrotar mudanças de browser e parser.

O serviço hospedado tira uma parte da infraestrutura das suas mãos. Em troca, você passa a depender de créditos, disponibilidade e comportamento da API. A integração por HTTP reduz dependência do nó n8n, mas não elimina diferenças de payload, preço e resposta entre fornecedores.

Crawl4AI mostra o outro lado. O projeto documenta instalação via pip, setup de browser Playwright e imagem Docker. Isso dá mais controle sobre browser, cookies, proxy e hooks. Também adiciona ambiente, atualizações, observabilidade e tempo do operador.

Não existe vencedor universal. Se extração é parte central do produto e você precisa de regras muito específicas, operar a pilha pode ser justificável. Se ela é infraestrutura auxiliar, pagar pela operação pode liberar tempo para o que o cliente realmente percebe.

Quando Apify, ScrapingBee ou Crawl4AI são escolhas melhores

A decisão deve considerar operação, não apenas o preço inicial anunciado.

A tabela de preços do Apify exibe plano Free com US$5 de uso e US$0,20 por compute unit. A plataforma se organiza em Actors e marketplace, o que ajuda quando um coletor pronto resolve uma fonte específica.

O ScrapingBee exibe Hobby por US$19,99 ao mês, 75.000 créditos e concorrência 25. Sua tabela cita renderização JavaScript, proxies rotativos ou premium e geotargeting. É uma alternativa quando uma API de scraping mais direta encaixa melhor na sua integração.

O Crawl4AI é o caminho para quem aceita operar a infraestrutura. Open source não significa custo zero. Significa que a conta muda de API para infraestrutura e trabalho técnico.

ToS, robots, LGPD e os dados que seu workflow não deve coletar

Renderizar uma página não resolve autorização. Robots.txt e termos de uso continuam sendo sinais e regras relevantes. Quando há dados pessoais, a análise também depende de finalidade, base legal, minimização e do que será feito depois com o resultado.

Não use um agente para ampliar sem critério uma coleta de leads ou perfis. Comece pelo mínimo: fonte pública e permitida, campo necessário, retenção curta e trilha de origem. Se o caso envolver dados pessoais ou alto impacto, procure orientação jurídica adequada. Este artigo não substitui parecer legal.

Também não trate claims de cobertura, latência ou sucesso como benchmark independente. A pesquisa não encontrou benchmark comparável entre Firecrawl, Apify, ScrapingBee e Crawl4AI. Faça um teste controlado com URLs permitidas se desempenho for um requisito do seu produto.

Perguntas frequentes sobre Firecrawl no n8n

Firecrawl funciona no n8n Cloud e no self-hosted?

A Firecrawl mantém guia oficial para n8n e um repositório do nó comunitário. O caminho com HTTP Request é especialmente útil quando uma operação v2 ainda não aparece no nó que você instalou. A disponibilidade exata depende da versão do n8n, do nó e da API que você está usando. Antes de levar o fluxo à produção, confira a documentação de integração e teste com uma chave mantida em credencial.

Como passar a API key sem deixá-la no workflow?

Armazene a chave em credencial ou secret do n8n e referencie-a no header Authorization. Não cole o token em um nó Set, URL, comentário ou captura de tela. A documentação do MCP também recomenda secret storage ou variável. Essa prática não é cosmética: ela evita que um export de workflow ou um log transforme uma credencial ativa em vazamento.

Quando usar Scrape, Map ou Crawl?

Use Scrape quando já tiver uma URL. Use Map para descobrir URLs em um domínio e filtrar as relevantes. Use Crawl quando precisar percorrer várias páginas e puder lidar com job assíncrono, ID, status e polling. Search atende melhor a descoberta por consulta. A escolha certa vem da entrada e da saída desejada, não do número de recursos de cada operação.

Quanto custa testar Firecrawl?

Na captura de 22 de agosto de 2026, o plano Free oferece 1.000 créditos mensais por US$0 e duas requisições concorrentes. Para páginas simples, Scrape, Crawl e Map aparecem com consumo de um crédito por página. Isso permite testar um fluxo pequeno. Confira a tabela atual antes da compra, sobretudo se usar Search, Interact ou Agent.

Firecrawl substitui um crawler próprio?

Ele pode substituir parte da operação para quem quer extrair e normalizar conteúdo sem manter browser, proxy, fila e parser. Não substitui decisões de produto, qualidade, política de coleta, armazenamento, retry ou LGPD. Se a extração for o núcleo do seu produto e exigir controle profundo, uma pilha própria como Crawl4AI pode continuar sendo a escolha mais adequada.

Quando Apify ou Crawl4AI são melhores?

Apify tende a fazer mais sentido quando há um Actor ou recurso de marketplace que atende exatamente sua fonte. Crawl4AI faz sentido quando você quer controlar a pilha, aceita operar Playwright e Docker e precisa de regras específicas de browser, cookies, proxy ou hooks. Não há benchmark independente nesta pesquisa para declarar uma ferramenta mais rápida ou mais confiável em todos os cenários.

Conclusão: compre operação quando ela não é seu diferencial

Firecrawl e n8n formam uma combinação pragmática para transformar URLs permitidas em contexto rastreável para RAG e agentes. Comece no plano Free, limite domínios, registre créditos e trate Crawl como job assíncrono. Só depois aumente volume.

Se a infraestrutura de scraping não diferencia seu produto, vale avaliar a oferta do Firecrawl no Runzos. Consulte as condições atuais na página antes de contratar. O ganho não é uma promessa de coleta sem falhas. É trocar manutenção recorrente por uma API que o seu workflow consegue governar.