You are viewing the documentation of the new API versions. We would love to hear from you. You can write to use at support@crustdata.co for feedback and clarifications.
Use this file to discover all available pages before exploring further.
POST /screener/web-search
POST /web/search/live
This page lists every behavioral and contract change between the legacy
web-search endpoint and the current one. Use it as a side-by-side
reference when porting an integration; each section gives the old shape,
the new shape, and the smallest edit that closes the gap.
Topic
Legacy
Current
Path
POST /screener/web-search
POST /web/search/live
Method
POST with a JSON body
POST with a JSON body
Auth
Authorization: Token <key>
Authorization: Bearer <key>
Version
(not required)
x-api-version: 2025-11-01 (required)
Base URL
https://api.crustdata.com
https://api.crustdata.com
Two header changes are required. The authorization scheme moved
from Token <key> to Bearer <key>, and the
x-api-version: 2025-11-01 header is now required on every call.
Calls missing either header are rejected.
The companion content-fetch endpoint has also moved — the legacy
?fetch_content=true query parameter and the standalone
POST /screener/web-fetch route are replaced by
Web Fetch at
POST /web/enrich/live. Both endpoints are now strictly separated.
The request shape is mostly preserved. Three parameters were renamed
(camelCase to snake_case), one was renamed semantically
(solveCloudflare → human_mode), and the ?fetch_content=true query
parameter was removed in favor of calling the dedicated fetch endpoint.
Legacy key
Current key
Notes
query
query
Required. Same semantics. Max length raised from 1000 to 5000 characters.
geolocation
location
Renamed. Same ISO 3166-1 alpha-2 country codes (US, GB, JP, …).
Renamed to snake_case. Same Unix-seconds timestamp.
endDate
end_date
Renamed to snake_case. Same Unix-seconds timestamp.
solveCloudflare
human_mode
Renamed. Same boolean semantics — attempt a browser-like retrieval path when standard access is blocked. Now neutrally named.
numPages
page
Renamed. Now represents the page number to fetch (1-indexed), not “number of pages to fetch in one call”. Call repeatedly to paginate.
?fetch_content=true (query string)
(removed)
Augmented fetch is no longer offered on this endpoint. Call Web Fetch at POST /web/enrich/live separately.
numPages → page is a semantic change, not just a rename. The
legacy numPages meant “fetch N pages of results in a single
call”. The current page means “return page number N”. To fetch
multiple pages, call the endpoint once per page.
The legacy endpoint accepted a ?fetch_content=true query parameter,
which augmented the response with fetched page contents under a
contents array. This parameter has been removed. To retrieve page
content for search-result URLs, call
Web Fetch at POST /web/enrich/live
with the URLs returned by /web/search/live.
The legacy numPages parameter retrieved up to N result pages in a
single response. The current endpoint serves one page per call via the
page parameter. Pre-check your credit budget before paginating
aggressively.
The response envelope is the same overall, but two fields under
metadata were renamed and failed_pages / empty_pages were added
for paginated diagnostics.
The legacy response returned the same per-result shape for all sources.
The current response carries a top-level source field on each entry
and adds source-specific fields. Common fields (title, url,
snippet, position) are unchanged.
Legacy field
Current field
Notes
title
title
Unchanged.
url
url
Unchanged.
snippet
snippet
Unchanged. Present for web, news, scholar-articles results.
position
position
Unchanged. 1-indexed.
(new)
source
The source type that returned this result (web, news, scholar-articles, …).
Source-specific additions on the current endpoint:
Source values are unchanged: news, web, scholar-articles,
scholar-articles-enriched, scholar-author, ai, social.For the per-source response shape and recipe-style usage, see
Web Search sources.