How to track competitor hiring with a scheduled weekly scan

What does a weekly scan of a named competitor return?

One company record per name, plus one flat row per job when emitJobRecords is on. The record opens with company_query and matched_company_name, so you can see which employer the boards resolved your input to. has_active_postings answers the yes or no question, active_jobs_by_site splits the employer-verified postings between Indeed and ZipRecruiter, and active_jobs_total_by_site.zip_recruiter reads the company's full open count from its ZipRecruiter page rather than the sample this run pulled. Indeed exposes no such total, so that slot is null. posted_last_48h_count tells you how many postings landed inside your recency window, which you set with hoursOld. Under profile sit industry, employee count, revenue band, headquarters, founding year and employee rating, with Indeed keys and ZipRecruiter keys side by side. latest_jobs nests the postings with title, location, salary fields, job_type, is_remote, job_level, posted_at and reposted_at. sites_with_errors names any board that failed for that company, and scraped_at stamps the run in UTC so each week's dataset sorts cleanly against the last.

• Sample record in the README: 17 Indeed and 21 ZipRecruiter postings found, live ZipRecruiter total 593, 17 posted inside the window
• Profile keys include company_industry, company_num_employees, company_revenue, zr_rating, zr_headquarters and zr_year_founded
• Each nested job also lands as a flat record_type: job row for spreadsheet-friendly exports
• posted_at is hour-precise on ZipRecruiter and day-precise on Indeed
• sites_with_errors lets you rerun only the companies where one board failed

How do you schedule a weekly competitor scan on Apify?

Start with the companies input. Write each competitor as name and website, for example Kelly Services | kellyservices.com, because domain matching stops a generic name from pulling in unrelated employers; the normalized-name fallback is controlled by matchThreshold, default 0.82. Leave scanMode on companies and recencyMode on last48h, then set hoursOld to 168 so a run captures everything posted since the previous one; the field accepts 1 to 720 hours. maxJobsPerCompany caps the rows per company per board at 50 by default and 200 at most, which is where you control dataset size. Keep both sites enabled unless one board is irrelevant to your market, set countryIndeed if your competitors hire outside the US, and keep the residential proxy, since ZipRecruiter rate-limits datacenter IPs. Save the input, then create an Apify schedule with a weekly cron and attach a webhook that fires on run completion. A ten-company run with the default window finishes in a few minutes; split lists of several hundred names across schedules so each run stays inside the 60-minute default timeout.

• companies: Name | website per line, or {name, website} objects through the API
• hoursOld 168 with recencyMode last48h covers a full week between runs; latest10 returns the 10 newest postings regardless of age
• maxJobsPerCompany: 50 default, 200 maximum, per company per board
• countryIndeed accepts usa, uk, canada and others; ZipRecruiter covers the US and Canada
• Turn includeDescription on only if you need full job text, since it adds latency on Indeed
• Weekly schedule plus completion webhook makes the run hands-off after the first setup

How do you diff two weekly runs to spot a hiring shift?

Every run writes its own dataset, so the comparison is a join on company_query between this week's export and last week's. Three deltas carry most of the meaning. The change in active_jobs_total_by_site.zip_recruiter is the volume signal: a jump means new requisitions were approved, a drop means roles closed or a freeze started. posted_last_48h_count, with the window set to 168 hours, counts only what appeared since your last run, so it doubles as a velocity number without any date math on your side. The third delta is in the job rows: new title strings that did not exist last week, new locations, and new values in job_level. Filter out rows that carry reposted_at before counting, because a bumped ad is not a new opening and would inflate the week's total. Keep scraped_at on every row and append each run to one table; after a quarter you have a dated series per competitor that a pivot or a notebook can chart directly.

• Join key: company_query, which echoes the exact name you submitted
• Volume delta: active_jobs_total_by_site.zip_recruiter this week minus last week
• Velocity: posted_last_48h_count with hoursOld at 168, no date parsing needed
• Novelty: titles, locations and job_level values absent from the previous run
• Exclude rows with reposted_at from new-opening counts; track them separately as hard-to-fill roles
• Use the companies and jobs dataset views for pre-flattened tables before joining

Which week-over-week changes are worth acting on?

Counts on their own tell you that something moved; the job rows tell you what. A competitor whose first posting in a new country or metro shows up in location is opening a market, and it usually appears there before any announcement. A cluster of engineering titles that share a product name points to a build in progress, while a batch of account executive or customer success roles points to a go-to-market push. job_level shifting upward, with director and VP titles appearing where individual contributor roles used to be, suggests a new function being stood up. salary_min and salary_max on each row put a number on how aggressively they are bidding for talent against your own bands. On the negative side, a falling live total with no fresh postings for two consecutive runs reads as a freeze, and reposted_at stacking up on the same title reads as a role they cannot fill. The profile block adds the employee rating, which moves slowly but frames retention.

• New location value for a competitor: market entry, so check which function leads the titles
• Cluster of titles sharing a product or platform name: a build underway
• Sales and customer success roles appearing together: a go-to-market push
• job_level moving to director and above: a new function or leadership layer
• Live total falling for two runs with zero fresh postings: freeze or restructuring
• reposted_at repeating on one title: a role they are struggling to fill

How do you get the weekly diff into a dashboard, CRM or AI agent?

The run finishes, the webhook fires, and the dataset is ready. The REST endpoint for dataset items returns JSON, CSV or XLSX, and the jobs and companies views give you two pre-flattened tables ready for a warehouse or a Google Sheet. The Python and JavaScript clients wrap the same call for teams that want to run the diff in a notebook or a cron job. On the no-code side, the actor's Integrations tab on Apify lists Zapier, Make, Google Sheets, Airtable and Slack, so a Slack post per competitor whose live total jumped is a few clicks. For agents, the scraper is exposed as an MCP tool at mcp.apify.com, which lets a Claude or ChatGPT based assistant answer a question like which of these competitors opened new roles this week by running the scan and reading the rows. Pay-per-call flows over X402 and MPP are supported for agents without an Apify subscription. Combine it with the other job boards in the Datapika catalog at /scrape when a competitor hires mostly through LinkedIn or Glassdoor.

• REST: dataset items endpoint with format=json, csv or xlsx, plus the jobs and companies views
• Python: pip install apify-client, then actor('openclawai/indeed-ziprecruiter-scraper').call(run_input={...})
• MCP: https://mcp.apify.com/?tools=fetch-actor-details,openclawai/indeed-ziprecruiter-scraper
• No-code: Zapier, Make, Google Sheets, Airtable and Slack from the Integrations tab
• Webhook on run completion triggers the diff step or the Slack alert

Questions, answered

Keep reading