extract by Firecrawl

extract works two ways. You can write a natural language prompt that describes the data you want, and the model picks a sensible shape for it. Or you can supply a JSON schema, so every record comes back with the exact fields and types you defined. Teams that need a stable shape for a database pick the schema; teams exploring an unfamiliar site start with a prompt and tighten it later.

You can point extract at a single page, a short list, or a whole site. A URL with a wildcard, like example.com/*, tells Firecrawl to crawl the domain and parse every page it can find before extracting the fields. That turns a site-wide hunt into one call, so you don't have to assemble the URL list yourself. The full-domain mode is marked experimental, so expect to check results.

Setting the web search option lets the extraction reach beyond the URLs you gave it. Firecrawl follows related pages to fill in missing context, which helps when a single page doesn't carry everything you need. One documented example pulls dash cam prices, features and reviews by starting from one product page and letting the search widen the net.

extract runs as a job, not a blocking call. You submit the request and get a job ID back, then check the status endpoint until it reports completed. The states are completed, processing, failed and cancelled, so you can hook it into a queue or a background worker. Job results stay reachable through the API for 24 hours after they finish.

Firecrawl ships Python and Node SDKs, so you don't hand-roll HTTP calls. The Python client can take a Pydantic model as the schema, and the Node client accepts a Zod object, giving you typed, validated output. Both offer a start method that returns a job ID right away, plus a status method to fetch results when the job settles.

Extract now bills in credits, the same currency as the other endpoints. One credit equals 15 tokens on extract, while a basic scrape costs 1 credit per page. Credits are shared across every endpoint, so search results and page scrapes draw on one balance. That makes it easier to predict spend when a job mixes extracting and crawling.

Firecrawl marks extract as the older tool and points new work to /agent, its successor. Agent keeps the prompt and schema options but drops the URL requirement, so it can search and navigate on its own. If your use case is "find this data somewhere on the web," Agent is the path; if you already know the URLs, extract still does the job.