Quick answer
Querying Welcome to the Jungle's search index with no filter reports nbHits: 6360 in the response envelope — then refuses to page past result 1,000. Page 40 of that same query comes back HTTP 200 with a body that reads {"message": "you can only fetch the 1000 hits for this query"}. That's not a rate limit and it's not a block; it's Algolia's hard pagination ceiling, and it's baked into every Algolia-backed site, not just this one. The Welcome to the Jungle Jobs Scraper treats that ceiling as a first-class fact: it surfaces it in the run's status message and gives you query, country, contractType, and remote as facets so you can slice a 6,360-hit corpus into several sub-1,000 queries instead of silently losing 84% of it.
Why does a 200 response contain an error?
Because Algolia's own index — the one Welcome to the Jungle's frontend calls directly from the browser — enforces a 1,000-result cap per query on the free/standard tier, and it enforces it at the pagination layer, not the response status layer. The first page of any query looks completely healthy: 200, real JSON, a nbHits field truthfully reporting the full match count, and 20 or so listings in hits. Nothing about that first page tells you the query has more matches than the index will ever hand you. Only when you request page 40+ (at 25 hits/page, that's the 1,000-result boundary) does the response change shape — still 200, but now the payload is the error: you can only fetch the 1000 hits for this query.
A scraper that treats "response received, parse hits" as its only success condition will parse that error body as if it were a results page, get an empty or malformed hits array, and stop. The run finishes green. The dataset looks complete because nothing in the run log says otherwise — it just quietly tops out at 1,000 rows on any query broad enough to have more. That's a worse failure than a crash: a crash gets investigated, a silently-truncated dataset gets shipped to a customer's pipeline and trusted.
Is the ceiling really about the search index and not the target blocking us?
Yes, and the distinction matters because they call for opposite fixes. A block calls for better fingerprinting, proxy rotation, or backoff. A 1,000-hit ceiling calls for narrower queries. We confirmed which one we were looking at by checking the same query with a tighter facet: narrowing by country=FR plus a keyword cut nbHits from 6,360 to under 1,000, and paging that narrower query all the way through returned every result with no error body — same site, same session, same browser fingerprint, no block anywhere in the run. The ceiling moved when the query got smaller; a block wouldn't have.
The second finding sits one layer below the pagination cap: the endpoint gates on the request's Origin / Referer header, not on the User-Agent or TLS fingerprint. A request with no origin header returns 403 {"message":"Method not allowed with this referer"} regardless of which browser you're impersonating. Both chrome131 and firefox133 impersonation profiles pass cleanly once the header is set to the site's own origin — the fingerprint was never the gate here, the header was. Worth knowing before you spend a debugging session rotating TLS profiles against a header check.
A
200status code tells you the transport succeeded, not that the payload is a results page. On any Algolia-backed search, check whether page N+1 still parses as a hit list before you trust that a broad query returned everything it claimed to have.
What the Actor gives you
One row per job listing, with the site's own facets available as scrape-time filters (not just export-time ones): objectId, title, slug, jobUrl, companyName, companySlug, offices (city/state/country per office), contractType + contractTypeLabel, remote policy, publishedAt (ISO-8601), salary range and currency when the recruiter published one, sectors, profession, and department. Set query, country, contractType, or remote — alone or combined — to keep any single search's true match count under the 1,000-hit ceiling.
Honest limitations 🚧
The 1,000-hit-per-query cap is real and not something we bypass — you narrow around it with facets, you don't get past it with retries or a different proxy. Full job-page HTML (benefits copy, application forms) isn't included; the search index already carries everything relevant to filtering and ranking, and a detail-page fetch would be a different, heavier Actor. Company-profile enrichment (reviews, culture pages) is out of scope for v1.
FAQ
Why did my broad search return exactly 1,000 rows when the listing count looked higher?
You hit the Algolia index's pagination ceiling. Split the query by country, contractType, or remote and run it again — each narrower query gets its own 1,000-hit budget.
Does this need a login or API key?
No — listings are public, and we call the same index endpoint the site's own frontend calls.
Why did my run return zero rows instead of failing?
A query + filter combination with no matches is a successful search, not a broken one. The run status message says exactly what was searched.
$0.20 per run plus $0.0025 per result — $2.70 per 1,000 results. A zero-match search still succeeds and costs only the start fee.
→ Welcome to the Jungle Jobs Scraper on Apify
Built by Devil Scrapes. We rotate browser fingerprints, retry with backoff, and route every request through Apify Proxy — and when a target's own search index caps what any single query can return, we tell you in the run status instead of shipping you a quietly truncated dataset.
