CrawlVolt
<- Field NotesGuide / 6 min

Scrape, crawl or browser session?

Choose the smallest primitive that can reach the data. More browser state means more cost, more failure modes and more cleanup.

A single page, a site corpus and an authenticated workflow are different jobs. Forcing them through the same long-lived browser makes the integration harder to operate.

01

Start from scope and state.

NeedPrimitiveWhy
One known URL/v1/scrapeOne bounded render and extraction result.
Many pages on one origin/v1/crawlDepth, page and path limits stay explicit.
Clicks or form input/v1/browseActions are ordered, metered and observable.
Login state across calls/v1/sessionsThe encrypted cookie jar stays server-side.
Discover relevant sources/v1/searchQuery web, news or images before extraction.
02

Keep each request bounded.

Create an API key or create an account before running the example. Replace your_api_key with the secret shown at creation.

Terminal
export CRAWLVOLT_API_KEY="your_api_key"
curl https://www.crawlvolt.com/v1/crawl \
  -H "Authorization: Bearer $CRAWLVOLT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://www.crawlvolt.com/docs/quickstart",
    "max_pages": 5,
    "max_depth": 1,
    "include_paths": ["/docs/**"],
    "formats": ["markdown"]
  }'

For a downloadable collection script, follow the documentation collection guide. See Crawl, Map and Search for request limits, and sessions for retained browser state.

The crawl stays on the exact origin, skips binary assets and applies include filters before excludes. Successful pages use the same output model and shared credit wallet as scrape.

03

Escalate capability only when the workflow needs it.

Selection rule

Scrape before crawl. Crawl before browse. Add a persistent session only when state must survive across requests.

This ordering minimizes browser time, narrows failure scope and makes retries easier to reason about.