Firecrawl integration for AI Flowi Workflow

Choose Crawl, Extract, Map or Scrape for URL-based retrieval with exactly 4 components in the firecrawl category of the AI Flowi Workflow 1.9.2 catalogue, exported 9 October 2026.

Firecrawl workflow cost references: plan pricing and the automation cost guide.

By Ai Flowi · Published 9 October 2026

Official source: Firecrawl documentation

documented in the catalogue; not production-tested by Ai Flowi

Use the shared credential overview for background; the operation-specific destination fields and JSON options are detailed here.

All 4 Firecrawl components

The inventory is limited to the four direct entries under firecrawl, rather than the separate Firecrawl component in composio. Exact display names, descriptions and required-input flags follow the supplied export.

All four operations require api_key as a string with an empty accepted-type list. Crawl and Scrape require singular url; Extract and Map require plural urls, also typed as a string.

Catalogue reference: Firecrawl category. On mobile, the table columns scroll horizontally; keyboard users can focus each region and press the arrow keys.

Related: Apify Integration.

Optional Firecrawl inputs and listed choices

The optional controls differ by operation, so copying one configuration into all four components would discard those distinctions. Data and JSON are the listed connection types for the object-like option fields.

Firecrawl output ports

Crawl, Extract, Map and Scrape each declare one output: display name JSON, internal name data, type JSON. The export contains no example response body for any of these four operations.

Configure the Firecrawl credential and operation

1. Enter the Firecrawl API key in the selected component’s required api_key input. A model-provider credential or saved Google-account selector is not the documented credential field for these operations.
2. For Firecrawl Crawl API or Firecrawl Scrape API, supply the target in url. For Firecrawl Map API, use urls. Each of those required string inputs lists Message as its accepted connection type.
3. For Firecrawl Extract API, fill both urls and prompt; both are required strings accepting Message. Add optional schema through Data or JSON if your configuration needs it. The catalogue does not define how several URLs are encoded in the plural-named field.
4. Set only the options appropriate to the action: Crawl accepts crawlerOptions, scrapeOptions, idempotency_key and timeout; Scrape accepts extractorOptions, scrapeOptions and timeout. Map has three sitemap/subdomain boolean controls, while Extract has optional enable_web_search.
5. Try the selected action against a test URL you can inspect, then examine data before adding downstream processing. Record which returned fields your next node needs instead of assuming identical response envelopes across the four actions.

For credential reuse, read the documented variables mechanism and check its availability on the field in your editor; the catalogue does not list a Firecrawl saved-connection selector or describe secret storage.

Three example workflow ideas

The following combinations outline possible jobs, with URL selection and payload inspection left explicit rather than supplied as a validated import.

1. Prepare structured facts from a selected page — not production-tested

Configure Firecrawl Extract API with api_key, a target in urls and instructions in prompt. If needed, connect a prepared Data or JSON value to optional schema. Inspect the JSON result before passing it to JSON Operations for your field-selection step; the catalogue does not promise that the result satisfies the supplied schema.

2. Map a site, then inspect a chosen URL — not production-tested

Use Firecrawl Map API with api_key and urls, deciding whether to set ignore_sitemap, sitemap_only or include_subdomains. Review its JSON output and select a URL for Firecrawl Scrape API‘s required url. Begin with manual selection until you have verified the map response’s layout; configure the API key on the scrape node too.

3. Turn inspected crawl data into a review note — not production-tested

Run Firecrawl Crawl API with api_key and url, adding Data or JSON crawlerOptions or scrapeOptions only after checking their supported structure. Once you have examined data, use Parser’s reference to plan a Message output for a review note. Its template configuration must match the observed crawl fields; no particular content key or formatting result is asserted.

What Firecrawl limitations should I check?

• Plural field names do not define a URL-array format. Extract and Map expose urls as str accepting Message, not as a Data or JSON input. The export does not provide a delimiter, JSON-string format or multi-URL validation rule.
• Option schemas and defaults are missing. crawlerOptions, scrapeOptions, extractorOptions and schema accept Data or JSON but list no supported keys. A boolean enable_web_search does not document search coverage, and the Map flags have no stated precedence when combined.
• Timeout and idempotency need verification. Crawl and Scrape list timeout as an optional integer without a unit, default or range. Only Crawl lists idempotency_key; its presence does not establish a retention window, retry policy or duplicate-prevention result.
• JSON is a port type, not a response specification. The four data outputs do not describe URL fields, text fields, extraction envelopes, job identifiers, polling behavior or partial-failure results. Inspect the response for the exact operation before building a selector.
• Category coverage stops at these four actions. No separate crawl-status, cancellation, scheduling or webhook component is listed here. The catalogue also leaves authentication failures, provider quotas and error recovery undocumented.

Related references

• Firecrawl category index
• Other workflow integrations
• API Request configuration reference
• Message, JSON and Table conversion reference
• Template library and recorded test scope