TRUEFETCH PREVIEW · Explore the designs. API access is not open yet. Release status ↗

Journal / Guide

Crawling, scraping or an API: start with the output you need

Choose between URL discovery, field extraction and a documented interface without confusing their responsibilities.

TrueFetch editorial · · Documentation and design analysis

A list of URLs, a set of readable pages and a table of job records are different deliverables. “Web scraping” is often used to describe all three, but your implementation needs to state which job is actually being done.

Crawling discovers a scope

A crawler follows or enumerates URLs according to a policy. The useful questions include which hosts and paths are allowed, how duplicates are handled and when traversal stops. Discovering a URL does not prove that the page was retrieved successfully or that its contents were extracted correctly.

Scraping extracts a representation

Extraction turns retrieved content into selected fields or another representation. A readable Markdown page can be useful for research; a structured record is more appropriate when software needs a company, location and source URL. A syntactically valid JSON object can still omit required fields or contain stale information.

Apify’s conceptual guide discusses the distinction. It is a vendor explanation, not independent performance evidence. When choosing tools, compare the responsibility each one covers rather than assuming that a parser, crawler and hosted dataset are interchangeable products.

An API defines an interface

An API tells your application how to ask for an operation and interpret its response. It may expose official data, run a collection job or deliver an existing dataset. The word “API” alone does not establish freshness, coverage, source authorization or record quality.

For a concrete task, prefer an existing documented interface when it provides the required output under suitable access conditions. If it does not, identify the missing capability before choosing a collection workflow. Check the provider’s current documentation rather than assuming a public website has an unrestricted official API.

Write the acceptance criteria first

For a job-listing workflow, define the geography, sources, fields, time window and duplicate policy. Decide whether partial coverage is acceptable. Then ask each implementation to produce the same useful output. Keep discovery counts, fetched pages and accepted records as separate metrics.

A sample pipeline might discover 20 pages, fetch 18 and accept 12 unique records. Those are hypothetical counts, not a TrueFetch test. Reporting only “20 successful results” would conceal two retrieval failures and the extraction and deduplication decisions.

Our source-outcome explanation shows why a result should retain that context. The Job Scraper preview demonstrates the planned contract locally; it does not crawl or collect any live data.