JobBKK Jobs Search Scraper

Extract complete public job records from JobBKK search and detail pages. The Actor uses lightweight HTTP requests and source-provided JobPosting JSON-LD; it does not require credentials or bypass access controls.

Modes

• search: discover detail URLs from startUrl, bounded by maxPages.
• single: fetch one public detail URL.
• multiple: fetch public detail URLs.
• startUrls: accept a mixture of listing and detail URLs.

maxItems counts only complete, unique records. Incomplete or mismatched candidates are excluded from the dataset and documented in DIAGNOSTICS. Search mode examines a bounded surplus of candidates so one incomplete posting does not silently reduce a healthy run. Cloud runs use Apify Proxy when available, while local runs may fall back to direct public access. maxRequests and maxResponseBytes bound network cost and response size.

Input example

{
  "mode": "search",
  "startUrl": "https://www.jobbkk.com/jobs/lists",
  "maxItems": 10,
  "maxPages": 2,
  "maxConcurrency": 3,
  "requestTimeoutSecs": 30,
  "includeRawJsonLd": false
}

Keep maxPages, maxItems, and concurrency conservative. Direct public access currently works; no proxy is required by default.

Output

Every dataset row contains a stable JobBKK ID, canonical URL, title, employer, plain-text description of at least 80 characters, non-empty location, and source-backed application URL. Available dates, salary, employment type, category, company URL, and logo are included without invented placeholders. Rows are marked complete, detail-verified, and include a content hash, field coverage, and cloud/proxy quality metadata. Request receipts and diagnostics are stored in KVS, never as dataset rows.

The platform lifecycle is separate from the collection outcome. platformStatus is only SUCCEEDED or FAILED; resultStatus is COMPLETE, LIMITED, SKIPPED, DEFERRED, NO_DATA, or FAILED. Explicit HTTP 401/403/429/451 or visible source-authored denial/challenge evidence stops scheduling, cancels active detail requests, discards staged rows, and reports SUCCEEDED/SKIPPED. Generic network/tool/transport errors report DEFERRED; if rows were stored before a later non-block error, the run remains SUCCEEDED/LIMITED. Fatal zero-row errors call Actor.fail() and report FAILED/FAILED. Dataset counts advance only after a successful Actor.pushData().

Run evidence is stored separately:

• RUN_SUMMARY: status, counts, quality metrics, timing, and local/cloud provenance.
• DIAGNOSTICS: failed requests and rejected candidates.
• SOURCE_RECEIPTS: safe URL/status/attempt/timing evidence without headers, cookies, or bodies.

Local development

npm test
npm run lint
apify run --purge --input-file test/fixtures/smoke-input.json
npm run validate:dataset

Deploy with apify push, then run a small cloud input and compare its dataset and KVS receipts with the local smoke run.