Apify Jobs Data

Jobs Data

Extract clean, structured job-posting data from 20+ boards in one Apify run, then put it to use. The pipeline is the same regardless of purpose:

acquire → de-noise → normalize → { analyze | export | rank by résumé }

The reusable value is the cleaned dataset: postings deduplicated across boards, cross-board reposts merged, likely ghost jobs flagged, and fields normalized to a consistent schema. Ghost-job and repost pollution corrupts demand counts, salary statistics, and dashboards just as much as it wastes a job seeker's time — so de-noise is the shared core, and every output mode runs on top of it.

Never invent a posting, a salary, a count, or a keyword. Everything is scraped live from a named Apify Actor and carries its source; missing fields stay blank, and every statistic reports the share of postings it is computed from — see Quality rules.

Ghost-job detection is heuristic and single-run: it compares the same (company, title, location) across boards for conflicting posted dates and reads the JD for pipeline language. The data carries no first-seen or edit history, so a flag is a suspicion, never a verdict. The Actors do the data work; the agent routes, de-noises, aggregates, and grounds:

Note on overlap with analysis-first job skills

A more analysis-first skill may also answer "hiring demand / in-demand skills / salary" questions. This skill's center of gravity is the cleaned dataset — cross-board duplicates and reposts merged, likely ghost jobs flagged, and fields normalized — which every mode then runs on. If you only need a quick market read, an analysis-only skill is lighter. Reach for this one when data quality matters (deduped demand counts, coverage-labeled salary stats), when you need the raw rows exported to CSV / an Apify dataset for a dashboard, or when you need a résumé ranked against live postings — none of which an analysis-only skill produces.

Output modes — pick one or more

The shared core (Steps 1–5) is identical; Step 6 produces whichever mode(s) the user wants. Default to whatever the request implies; if unclear, ask.

Cost discipline (best quality for the lowest cost)

This is a design goal, not an afterthought — keep every run as cheap as it can be while still answering the question:

• One cheap actor, no subscriptions. Default to the pay-per-result aggregator (≈ $0.0035/job + $0.01 start on the free tier, as of 2026-09-16 — check the live rate in reference/gotchas.md / the Apify console before quoting a number). A typical run is cents to a few dollars.
• Smallest sample that answers it. max_results is per platform (× every platform the Actor supports for the country unless platforms is pinned), so pin platforms and start small — a quick scan needs ~10–15/platform; a market analysis ~25–50/platform — and scale only if the result is too thin. Always estimate, and confirm before a big run.
• One run feeds every mode. Analysis, export, and résumé-fit all read the same scrape — never re-scrape to add a second mode.
• De-noise so you never pay for junk. Removing ghost jobs / reposts / duplicates keeps the billed sample honest and the counts real.
• For salary, prefer the Glassdoor benchmark over a mega-scrape. Salary disclosure is low (~2–6% in many markets), so scraping thousands of postings to harvest a few disclosed figures is wasteful — one cheap memo23/glassdoor-scraper-ppr call per company with maxItems ≤ 50 (its default is 20,000 rows per URL) gives a better signal for less.

Prerequisites

(No need to check this upfront.)

Two execution paths — pick the one that matches your environment.

MCP path (default in an agent session with MCP, recommended). If the Apify MCP server is connected, no setup is needed — auth runs through the user's Apify account. Use the call-actor, get-actor-run, and get-dataset-items MCP tools.

CLI path (scripted / non-interactive execution). Requires the Apify CLI v1.5.0+ and auth via apify login or an APIFY_TOKEN env var (get a token). Every CLI call in this skill carries three flags — --json, --user-agent apify-awesome-skills/apify-jobs-data, and 2>/dev/null (apify api prints JSON by itself and rejects --json — give it the other two).

Responsible use. These Actors scrape third-party boards (LinkedIn, Glassdoor, Indeed, ZipRecruiter and others) against those sites' Terms of Service — the user's call to make. All routes run on Apify's infrastructure (no user login), so they never put the user's own board accounts at risk.

Workflow

Copy this checklist and track progress.

Task Progress:
- [ ] Step 0: Pick the output mode(s)
- [ ] Step 1: Collect the query anchors (one block)
- [ ] Step 2: Route to the right board Actor(s) (primary + fallback)
- [ ] Step 3: Build the input, estimate cost, confirm if over threshold
- [ ] Step 4: Run, wait, pull the dataset
- [ ] Step 5: De-noise + normalize into clean rows
- [ ] Step 6: Produce the selected mode(s) — analysis / export / résumé-fit
- [ ] Step 7: Deliver, with provenance and coverage

Step 0: Pick the output mode(s)

Decide what the user wants done with the data — it changes only Step 6, not the shared core. Infer from the request; confirm if ambiguous:

• "what skills/salary/demand for X", "job-market for Y" → Market & salary analysis.
• "scrape / export / give me a dataset / CSV for a dashboard" → Structured export.
• "which of these fit my résumé", "rank these for me" → Résumé-fit (needs a résumé; anchor #7).
• Multiple are fine — e.g. analysis + export of the same run.

Step 1: Collect the query anchors

Ask these as one block before any Actor call. Defaults shown — always surface them so the user can override. (Anchor-block pattern from apify-verified-email-finder.)

1. Role / keywords — e.g. senior backend engineer. Required.
2. Location — city, country, or remote. Required. remote flips the remote-only filter on.
3. Boards — auto (default → aggregator, all boards the Actor supports for the country) or a named subset passed as the aggregator's platforms array (exact enum values from the live schema — e.g. LinkedIn, Indeed, Glassdoor; Google Jobs is not in the enum). Drives Step 2 and cost (Step 3).
4. Result cap — for the aggregator this is per platform (max_results: 25 ≈ 25 × the platforms hit — every platform the Actor supports for the country unless platforms is pinned), minimum 1. Start small (10–15 for a quick scan, 25–50 for analysis) and scale only if the sample is too thin — together with platforms it's the main cost lever, so budget max_results × platforms (Cost discipline, Step 3). Maps to each Actor's own field (max_results for the aggregator / maxItemsPerSearch for Indeed / maxItems for Glassdoor — actor-index.md).
5. Recency window — default 2 weeks. The aggregator takes this as a natural-language string ("2 weeks", "1 month"), not a day count.
6. Filters — optional constraints that drop a posting: salary_floor, remote_only, job_type (fulltime / contract / internship — no hyphen). Collect what the user volunteers.
7. Résumé / profile — only for résumé-fit mode: résumé text or a must-have + nice-to-have skill list. Without it, résumé-fit falls back to a mechanical score labeled Fit (partial).

Ambiguity rule: if role or location is missing or vague, ask one clarifying question before running. Never burn Actor compute on a guessed query.

Step 2: Route to the right Actor(s)

Default to the aggregator — one run, 20+ boards (LinkedIn, Indeed, Glassdoor, ZipRecruiter, and more; not Google Jobs), country-aware routing, cheapest per-result. Every Actor here is pay-per-result — no subscriptions. The aggregator already covers LinkedIn cheaply, so there is no need for a per-board LinkedIn subscription Actor. If the user asks for Google Jobs specifically, say this skill does not cover it.

Start with the aggregator unless the user explicitly wants a single board. Named boards stay in one run: if the user names one or more boards, pass them in the aggregator's platforms array (anchor #3) — a single run whatever the number of boards, never one Actor per board. The only standalone route chosen up front is misceres/indeed-scraper, and only when the user wants Indeed exclusively.

Per-board fallback rule: after the run, count rows per requested board that match anchor #2 (location). A board the user named that comes back with zero (or near-zero) in-area rows — blocked, or the Actor ignored the location, as Indeed's path does — gets one fallback run with its standalone Actor from the table (misceres/indeed-scraper for Indeed, capped with maxItemsPerSearch), if budget and run count allow; its rows carry their own Source board and are deduped against the aggregator's in Step 5. Only if budget or the run count is gone do you report the board as a coverage gap instead — a board the user asked for is worth that one capped run. The fallback is conditional on a measured zero: outside it, never run two Actors against the same query. Never a second aggregator retry for the same board — whatever the cause (blocked, location ignored, or TIMED-OUT before the board was reached); do the per-board in-area count first, and if the aggregator timed out, narrow platforms/max_results only in the first run's design, never in a rerun. Full schemas and field mappings: reference/actor-index.md.