EURAXESS Jobs Search Scraper

This Apify Actor reads the public EURAXESS search results and emits source-backed research-job records from visible result cards. A historical observation (2026-09-22) found public /jobs/{id} links redirecting to /jobs/search on the ordinary direct route; current source access was not checked during the offline lifecycle audit. The Actor therefore retains those URLs as unverified detail links and does not claim detail-page fields that it could not fetch.

Public input

{
  "query": "biology",
  "maxPages": 1,
  "maxItems": 3
}

The Actor uses ordinary direct HTTPS requests, sequential pagination, and no proxy, stealth, fingerprint, identity, retry, fixture, or temporary context controls.

Source fields

The existing parser handles job ID, title, offer type, country, organisation and profile URL, posted date, summary, department, work-location summary, research fields, researcher profile, funding programme, and application deadline when those values are present on an accessible card. This offline audit did not verify the current source fields. Records preserve parsed fields, normalized dates, arrays for visible labels, listing/detail URL provenance, request headers/status, source evidence, and quality counts.

detailEnriched and detailAvailable are explicitly false for the current run shape. This is intentional: a live Chrome click and an ordinary direct request to a public detail URL both returned to the search route, so no detail-only value is fabricated.

Access policy

HTTP 401/403/429/451 or a visible source-authored verification/access-denial challenge stops further requests and discards unpersisted staged jobs. The outcome is SUCCEEDED/SKIPPED if no eligible rows were stored, or SUCCEEDED/LIMITED if a stored prefix already exists. HTTP 407, redirects, unverified HTTP responses, response-read failures, transport failures, parser uncertainty, and zero-qualified-record quality outcomes are SUCCEEDED/DEFERRED; they are not treated as proof that EURAXESS blocked access. NO_DATA requires visible first-party empty-result evidence for every requested search. Fatal runtime or storage failures before any eligible row is stored are FAILED/FAILED; after a stored prefix they are SUCCEEDED/LIMITED. Diagnostics and request receipts are stored only in the key-value store, never in the jobs dataset. The Actor never switches proxies, identities, browser fingerprints, or alternate routes to work around a restriction.

The platform run status is always SUCCEEDED or FAILED; resultStatus separately describes COMPLETE, LIMITED, SKIPPED, DEFERRED, NO_DATA, or FAILED. Only successfully awaited pushData calls count as stored rows. A zero-row fatal runtime/storage failure calls Actor.fail() and reports FAILED/FAILED; eligible rows stored before a later failure are retained and reported as SUCCEEDED/LIMITED.

Output and validation

The strict dataset schema is .actor/dataset_schema.json; dataset rows are complete, source-backed job cards only. The Actor also stores OUTPUT_SUMMARY, REQUEST_RECEIPTS, RUN_DIAGNOSTICS, and OUTPUT in the default key-value store. OUTPUT_SUMMARY and OUTPUT expose separate platform and result statuses plus reconciled staged/stored counts.

npm install
npm test
apify validate-schema
apify run --purge --input-file ./INPUT.json
npm run validate:dataset -- storage

The validator requires actor-generated source-card records with successful direct listing receipts, honest listing/detail provenance, and more than 20 meaningful populated fields per record.