How do you use Firecrawl with n8n?

The two day cache default returns stale pages, and bills you anyway

Scrape defaults to a maxAge freshness window of two days, so a repeat request inside that window returns a cached result instantly. For a research pipeline that is usually what you want. For anything monitoring change, such as watching a prospect's careers page or pricing page, it means you can poll daily and never see the change you are polling for. Set maxAge to zero when freshness matters. Note that cached results still cost a credit per page, so caching saves time rather than money.

Crawl ignores links that are not children of the start URL

By default a crawl will not follow sublinks outside the start URL's path, unless crawlEntireDomain is set. This is a silent under-collection: the job succeeds, returns pages, and simply never visited the sections you assumed were included. A crawl of a company's /blog will not reach /careers unless you tell it to. Nothing in the result indicates what was skipped.

JSON mode is a five times multiplier and extract is token-metered

A plain scrape is one credit per page. JSON mode adds four, so structured extraction costs five credits per page rather than one. Extract is billed at one credit per fifteen tokens, which is unbounded in a way per-page pricing is not. Map, by contrast, is a flat one credit per call no matter how many URLs come back. A pipeline designed without knowing this asymmetry can cost several times what an equivalent one costs.

Crawl results vary between runs

Firecrawl documents this directly: page results may vary between runs because of concurrent scraping, and pages at the depth boundary explore branches inconsistently at high concurrency. If a workflow compares this run against the last one, some of the difference is the crawler rather than the website. Anything doing change detection needs to account for that or it will generate false positives.

Map is deliberately incomplete, and the vendor says so

Firecrawl's own documentation states that map prioritises speed and may not capture all website links, recommending crawl for comprehensive discovery. Teams reach for map because it is fast and flat-rate, then build on the assumption that it returned everything. It is the right tool for orientation and the wrong one for coverage.

Whether a failed scrape consumes a credit is not documented

We looked for this in the errors documentation, the scrape and crawl feature pages, and the GitHub issues, and found no statement either way. It is a reasonable question to ask before building a pipeline that retries aggressively, and we would rather tell you it is undocumented than guess. If retry cost matters to your budget, test it on a small volume before scaling.