# ATS Hiring Signal Monitor: Who Is Hiring, Week Over Week (`accountable_eel/ats-hiring-signal-monitor`) Actor

ATS hiring signal monitor: give it a company watchlist and get one row per company, not a job dump. Open roles, roles opened and closed since your last run, growth percent, job families, seniority mix and a verdict. Greenhouse, Lever, Ashby, Workable, SmartRecruiters, Personio.

- **URL**: https://apify.com/accountable\_eel/ats-hiring-signal-monitor.md
- **Developed by:** [Adrian Voss](https://apify.com/accountable_eel) (community)
- **Categories:** Jobs, Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $6.00 / 1,000 hiring signals

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## ATS Hiring Signal Monitor: Who Is Hiring, Week Over Week

This is a **monitor**, not a job scraper. Give it a list of companies, run it weekly, and every run
returns **one row per company**: how many roles are open, how many opened and closed since your last
run, which job families the new roles are in, the seniority and remote mix, and a one-word verdict —
`expanding`, `gtm-push`, `contracting` or `steady`. It never returns a job posting.

The general-purpose [ATS Jobs Scraper](https://apify.com/accountable_eel/ats-jobs-unified-lookup) can
produce this row too, but it ships as a job scraper: its default output is one row per platform match
with every posting inside, and the summary row is an option you have to find and switch on together
with two other checkboxes. Here the summary row is the only output, on by default, and billed as one
event per company instead of one per platform. If you want the postings themselves — titles,
departments, locations, apply links, new-posting alerts — use the parent actor; it is listed under
**Related actors** at the bottom.

### Who it's for

- **Outbound and GTM teams** using hiring as a buying signal. A company that just opened four SDR
  roles is in a different conversation from one that closed three.
- **Investors and analysts** tracking headcount direction across a portfolio or a comp set, without
  storing a job board.
- **Recruiters and agencies** watching which accounts are actually expanding, and in which function.
- **Anyone who tried a job scraper and drowned in it.** One row per company goes into a CRM or a
  spreadsheet; ten thousand postings do not.

### What this returns instead of job postings

| | A job scraper | This actor |
|---|---|---|
| Rows per company | one per platform, with every posting | exactly one |
| "Are they growing?" | you aggregate it yourself | `growthPct`, `newRolesSinceLastRun`, `closedRolesSinceLastRun` |
| "Growing where?" | you bucket titles yourself | `newRoleClusters`, `hiringFor`, `topDepartments` |
| "In one word?" | not available | `signal` + `signalReason` |
| Billing | per platform matched | once per company with a board |
| Fits a CRM column | no | yes |

### You do not need to know which ATS a company uses

One company slug is tried against all six platforms at once: **Greenhouse**, **Lever**, **Ashby**,
**Workable**, **SmartRecruiters** and **Personio**. Whichever one answers is the one you get, and a
company mid-migration with boards on two platforms is folded into a single row and a single verdict
rather than counted twice.

`atsDetected` is `false` (not blank) on a company where none of the six has a board, so a
company-list enrichment always has a definite answer in the cell. Those rows are free.

### How the week-over-week comparison works

Each company is remembered between runs, in your own account's storage.

1. **First run.** The baseline. Every company comes back with its current board size and
   `signal: "baseline"`. This is a real, billed row, and it is what run two compares against.
2. **Every run after.** The row gains `newRolesSinceLastRun`, `closedRolesSinceLastRun`,
   `growthPct`, `newRoleClusters`, `topDepartments`, `seniorityMix`, `remoteShare`,
   `comparedToRunAt`, and the `signal` verdict with a plain-English `signalReason`.
3. **Schedule it weekly.** The comparison is against *your previous run*, so the cadence you choose is
   the window you measure. Weekly is the usual choice; monthly works the same way.

The comparison costs nothing extra: it is computed from the row you are already paying for.

### Job families are yours to define

The five defaults (sales, engineering, marketing, customer-success, executive) are a starting point,
not the product. Replace them with the segments that matter to you:

```text
field-sales: account executive, enterprise ae, regional sales manager
implementation: solutions engineer, implementation, onboarding, professional services
data: data engineer, analytics engineer, data scientist, bi
compliance: compliance, risk, aml, kyc, legal counsel
```

Each company's row then carries `hiringFor` with `{hiring, count}` per family, and
`newRoleClusters` tells you which families the *new* roles landed in — which is the difference between
"they are hiring" and "they are building a sales motion".

### What you get

One row per company:

- **Detection** — `atsDetected`, `atsPlatform`, `atsPlatforms`.
- **Size** — `openRoles` (the true board size, not the size of the sample), `postingsSampled`.
- **Shape** — `roleCountsByDepartment`, `hiringFor`, `topDepartments`, `seniorityMix`, `remoteShare`,
  `sampleTitles`.
- **Change** — `newRolesSinceLastRun`, `closedRolesSinceLastRun`, `growthPct`, `newRoleClusters`,
  `comparedToRunAt`.
- **Verdict** — `signal` (`expanding`, `gtm-push`, `contracting`, `steady`, `baseline`) and
  `signalReason`.
- **Recency** — `newestPostingAt`, `postingsLast30d`, `postingsPrev30d`, `velocity30d`.

`velocity30d` is deliberately `null` rather than a big number when it would be meaningless: a board
whose postings carry no dates, or one that only opened last month, is not "infinitely accelerating".

The results open on the **Hiring signals** view by default, with a narrower **Hiring trends** view for
just the change columns.

### Price

- **Hiring signal**: $12 per 1,000 company slugs

Plus a $0.00005 start fee per run. Each event above is billed independently, only when it actually returns data — misses (`found:false`) are never charged.

- **One event, once per company** that has a board on one of the six platforms, plus a $0.00005 start
  fee per run.
- **A company with no ATS board is free.** It still gets a row, with `atsDetected: false`.
- **Two boards is still one charge.** A company mid-migration is one company.
- The week-over-week comparison is included. There is no separate event for it.

Worked example. A watchlist of 200 companies, run weekly: 200 × 4.3 = about 860 charged rows a month,
**about $10.32 plus 5 start fees** — roughly **$10.32 a month** for a full month of hiring direction
on 200 accounts. Companies without a board make it cheaper, not dearer.

### How to use

1. **In the Apify Console.** Open the actor page and click **Start** — the `companySlugs` field is already pre-filled with a working example. Results land in the run's dataset as soon as each item is found.
2. **Via the API.** Call it directly with a POST request — no Console needed once you have an API token:
   ```bash
   curl "https://api.apify.com/v2/acts/accountable_eel~ats-hiring-signal-monitor/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
     -X POST \
     -H "Content-Type: application/json" \
     -d '{"companySlugs":["stripe"]}'
   ```
3. **On a schedule.** Save this actor as an Apify **Task** with the input you want, then add a **Schedule** (hourly, daily, weekly) so it runs on its own — no server of your own required.

Tips:

- **Weekly is the right cadence.** The comparison window is the gap between your runs; a daily run
  mostly reports `steady` because boards do not move that fast.
- **Use the same watchlist name for a schedule.** Leave *Watchlist name* empty and every schedule of
  this actor shares one memory per company, which is what you want. Set a name only when you
  deliberately want two independent windows (say weekly and monthly) over the same list.
- **Redefine the job families before your first run.** They shape `hiringFor` and `newRoleClusters`,
  and the baseline is more useful if the segments are already yours.
- **Read from run two.** Run one is honest about being a baseline; it cannot invent a comparison it
  does not have.
- `includeKeywords` / `excludeKeywords` and *Hide rows with no result* work on the finished rows, so
  you can keep only the companies whose `signal` is `expanding` without paying for a second pass.

### Input

```json
{
  "companySlugs": [
    "stripe"
  ]
}
```

One company slug per line (e.g. "stripe"), or paste a full board URL from any of the six platforms below. The same slug is tried against all six, so you do not need to know which applicant-tracking system a company uses. Each company comes back as one summary row: how many roles are open, what changed since the last run, and a one-word verdict. Accepted formats: stripe, https://boards.greenhouse.io/stripe, https://jobs.lever.co/stripe.

### Sample output

| query | found | status | greenhouse | lever | ashby | workable | smartrecruiters | personio | scrapedAt |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| stripe | true | OK | <greenhouse match> | <lever match> | <ashby match> | <workable match> | <smartrecruiters match> | <personio match> | 1970-01-01T00:00:00.000Z |

A real row from the live smoke test (`stripe`, 2026-09-26), trimmed. Run one is the baseline, and
every field except the comparison ones is already filled:

```json
{
  "query": "stripe",
  "found": true,
  "status": "OK",
  "atsDetected": true,
  "atsPlatform": "greenhouse",
  "atsPlatforms": ["greenhouse"],
  "openRoles": 703,
  "postingsSampled": 703,
  "signal": "baseline",
  "signalReason": "First run of this watchlist: 703 open roles recorded as the baseline, with nothing to compare against yet.",
  "newRolesSinceLastRun": 703,
  "closedRolesSinceLastRun": 0,
  "growthPct": null,
  "seniorityMix": { "junior": 9, "mid": 550, "senior": 11, "lead": 133 },
  "hiringFor": {
    "sales": { "hiring": true, "count": 156 },
    "engineering": { "hiring": true, "count": 198 },
    "marketing": { "hiring": true, "count": 51 }
  },
  "newestPostingAt": "2026-09-25T22:57:49.000Z",
  "postingsLast30d": 287,
  "postingsPrev30d": 150,
  "velocity30d": 1.91,
  "comparedToRunAt": null,
  "scrapedAt": "2026-09-26T00:09:42.893Z"
}
```

`growthPct` and `comparedToRunAt` are `null` on a baseline row and filled from run two on.

### Use it from Clay, n8n, Make, or an AI agent

This actor runs synchronously over plain HTTP — call it directly from a script, a workflow tool, or an AI agent, no Apify Console needed once you have an API token.

```bash
curl "https://api.apify.com/v2/acts/accountable_eel~ats-hiring-signal-monitor/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"companySlugs":["stripe"]}'
```

**n8n.** Add an HTTP Request node: Method `POST`, URL `https://api.apify.com/v2/acts/accountable_eel~ats-hiring-signal-monitor/run-sync-get-dataset-items?token=<YOUR_TOKEN>`, Body Content Type `JSON`, JSON Body `{"companySlugs":["stripe"]}` (swap in an expression from an earlier node for a real value).

**Clay.** Add an "HTTP API" column: Method `POST`, URL `https://api.apify.com/v2/acts/accountable_eel~ats-hiring-signal-monitor/run-sync-get-dataset-items?token=<YOUR_TOKEN>`, Body `{"companySlugs":["{{company slug}}"]}`, mapping the row's company slug into the `companySlugs` array.

**MCP.** In Claude, Cursor, or any MCP client with the Apify MCP server, ask for "ATS Hiring Signal Monitor: New Roles Week Over Week" — the agent will find and run this actor.

One row per company is exactly the shape a CRM or an enrichment table wants: map `signal`,
`growthPct` and `newRolesSinceLastRun` onto the account record and you have a hiring-trend column
that updates itself every week.

### vs. alternatives

- **A job-board scraper.** Gives you postings. Turning thousands of postings into "is this account
  expanding, and where" is the work this actor has already done.
- **Hiring-signal data vendors** (TheirStack, PredictLeads and similar). Broader coverage and a
  matching price. This is the same signal for the companies *you* name, at cents per company, with no
  contract and no minimum.
- **The parent actor,**
  [ATS Jobs Scraper](https://apify.com/accountable_eel/ats-jobs-unified-lookup). Same engine, both
  modes: one row per platform match with every posting (title, department, team, location, remote
  status, apply link, published date), a new-postings-only watchlist mode, per-platform billing, and
  the same six platforms. Use it when you want the roles; use this one when you want the trend.

### Data & privacy

- **No login, no cookies, no account.** There is no input field that could take an ATS session, and
  none is needed: everything here comes from the public job-board endpoints companies publish for
  their own careers pages.
- **No personal data at all.** The output is counts, ratios, department and family names, up to five
  job titles, and timestamps. No candidate data, no recruiter names, no contact details.
- **The watchlist memory holds job IDs and board sizes only**, in your own account's storage, and only
  for the companies you submit.
- **Rate-limited and fail-soft.** A platform that is slow or refuses a request fails that one source,
  not the company and not the run, and an unmatched platform is never billed.

### FAQ

**The first run says "baseline" everywhere. Is it broken?**
No. There is no earlier run to compare against, so the first run records the board and says so. From
run two on you get the change.

**Do I get the actual job postings?**
No, by design. This actor returns one summary row per company. Use the parent actor for postings.

**What if I do not know which ATS a company uses?**
That is the point. The slug is tried against all six platforms and you are only charged when one of
them answers.

**Am I charged for companies with no job board?**
No. They come back with `atsDetected: false` at no cost.

**How is `openRoles` different from `postingsSampled`?**
`openRoles` is the true size of the board as the platform reports it; `postingsSampled` is how many
postings were read to build the row. SmartRecruiters pages at 100, so the two differ on large boards.

**Can I use my own job families?**
Yes — replace the five defaults with your own `family: keyword, keyword` lines. That is the single
highest-value thing to configure.

**What does `gtm-push` mean?**
That the new roles are concentrated in go-to-market families (sales, marketing, customer success)
rather than spread evenly. `signalReason` spells out the reasoning on every row.

### Related actors

- **[ATS Jobs Scraper: Greenhouse, Lever, Ashby + 3 More in One API](https://apify.com/accountable_eel/ats-jobs-unified-lookup)**
  — the parent, and the full-capability version: every open role from all six platforms with title,
  department, team, location, remote status, apply link and published date, a new-postings-only
  watchlist mode, per-platform billing, and this same hiring-signal row as an option.
- **[Greenhouse Jobs Scraper](https://apify.com/accountable_eel/greenhouse-jobs-lookup)** — one
  platform, every posting, with departments.
- **[LinkedIn Jobs Search Scraper](https://apify.com/accountable_eel/linkedin-jobs-search-lookup)** —
  keyword and location search rather than a company watchlist.

# Actor input Schema

## `companySlugs` (type: `array`):

One company slug per line (e.g. "stripe"), or paste a full board URL from any of the six platforms below. The same slug is tried against all six, so you do not need to know which applicant-tracking system a company uses. Each company comes back as one summary row: how many roles are open, what changed since the last run, and a one-word verdict. Accepted formats: stripe, https://boards.greenhouse.io/stripe, https://jobs.lever.co/stripe. You're only charged for the ones we actually find — a miss costs nothing.

## `mode` (type: `string`):

Pick the option that matches what you need — you can leave this on the recommended setting.

## `testRun` (type: `boolean`):

Turn this on to test your input on a small sample before running the full list. Turn it off to process everything.

## `onlyFound` (type: `boolean`):

Only keep rows where something was actually found. Misses are always free, whether or not you show them here.

## `includeKeywords` (type: `array`):

Optional. Only keep results that mention at least one of these words (e.g. a job title, a city, a product name). Leave empty to keep everything.

## `excludeKeywords` (type: `array`):

Optional. Drop any result that mentions one of these words. Leave empty to skip nothing.

## `maxResults` (type: `integer`):

Optional. Stop the run once this many results have been found — useful for a quick, cheap sample. Leave blank for no limit.

## `hiringForGroups` (type: `array`):

One job family per line, as "family name: keyword, keyword" — each company is then reported as hiring (or not) for that family, with a count. Keywords match inside the job title and case does not matter, so "engineer" also catches "Engineering Manager". Leave as-is for the five defaults, or replace them with your own segments (a territory, a product line, the roles that signal your own buying trigger).

## `deltaMode` (type: `boolean`):

On by default: this is what makes the actor a monitor rather than a snapshot. The watchlist memory records each company's board on every run, which is what lets the next run say how many roles opened and closed. Nothing is withheld from your results by this checkbox (a signal row summarises a whole board rather than listing postings), so every company you submit still comes back with a row and is still charged once. Turn it off only if you want a one-time snapshot with no week-over-week comparison.

## `deltaName` (type: `string`):

Leave empty and one is derived for you, so every schedule of this actor shares one memory per company and platform. Type your own name to keep two independent watchlists over the same companies, for example a weekly one and a monthly one.

## `signals` (type: `boolean`):

On by default. Adds the change since your last run to every row: roles opened and closed, percent growth, which job families the new roles are in, seniority mix, remote share, and a one-word verdict (expanding, gtm-push, contracting, steady). The first run of a watchlist is the baseline and reports "baseline", so schedule this weekly and read from run two on. It costs nothing extra: the comparison is computed from the row you are already paying for.

## `columns` (type: `array`):

Choose which sources to check. Only the sources you select here are checked — and only the ones that actually return data are billed. All are included by default.

## `maxConcurrency` (type: `integer`):

Parallel requests. Keep conservative — this target has no browser fallback, so getting blocked costs more than slow-and-steady.

## Actor input object example

```json
{
  "companySlugs": [
    "stripe"
  ],
  "mode": "signal",
  "testRun": false,
  "onlyFound": false,
  "includeKeywords": [],
  "excludeKeywords": [],
  "hiringForGroups": [
    "sales: sales, account executive, business development, sdr, bdr, account manager, revenue",
    "engineering: engineer, developer, software, devops, sre, data scientist, machine learning, architect",
    "marketing: marketing, demand generation, growth, content, brand, seo, communications",
    "customer-success: customer success, customer experience, customer support, technical support, implementation, onboarding, solutions consultant",
    "executive: chief, head of, vp, vice president, director, president"
  ],
  "deltaMode": true,
  "deltaName": "",
  "signals": true,
  "columns": [
    "greenhouse",
    "lever",
    "ashby",
    "workable",
    "smartrecruiters",
    "personio"
  ],
  "maxConcurrency": 5
}
```

# Actor output Schema

## `results` (type: `string`):

No description

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "companySlugs": [
        "stripe"
    ],
    "includeKeywords": [],
    "excludeKeywords": [],
    "hiringForGroups": [
        "sales: sales, account executive, business development, sdr, bdr, account manager, revenue",
        "engineering: engineer, developer, software, devops, sre, data scientist, machine learning, architect",
        "marketing: marketing, demand generation, growth, content, brand, seo, communications",
        "customer-success: customer success, customer experience, customer support, technical support, implementation, onboarding, solutions consultant",
        "executive: chief, head of, vp, vice president, director, president"
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("accountable_eel/ats-hiring-signal-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "companySlugs": ["stripe"],
    "includeKeywords": [],
    "excludeKeywords": [],
    "hiringForGroups": [
        "sales: sales, account executive, business development, sdr, bdr, account manager, revenue",
        "engineering: engineer, developer, software, devops, sre, data scientist, machine learning, architect",
        "marketing: marketing, demand generation, growth, content, brand, seo, communications",
        "customer-success: customer success, customer experience, customer support, technical support, implementation, onboarding, solutions consultant",
        "executive: chief, head of, vp, vice president, director, president",
    ],
}

# Run the Actor and wait for it to finish
run = client.actor("accountable_eel/ats-hiring-signal-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "companySlugs": [
    "stripe"
  ],
  "includeKeywords": [],
  "excludeKeywords": [],
  "hiringForGroups": [
    "sales: sales, account executive, business development, sdr, bdr, account manager, revenue",
    "engineering: engineer, developer, software, devops, sre, data scientist, machine learning, architect",
    "marketing: marketing, demand generation, growth, content, brand, seo, communications",
    "customer-success: customer success, customer experience, customer support, technical support, implementation, onboarding, solutions consultant",
    "executive: chief, head of, vp, vice president, director, president"
  ]
}' |
apify call accountable_eel/ats-hiring-signal-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,accountable_eel/ats-hiring-signal-monitor"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/npkVSSNarwM2Q52KB/builds/206qq3gSUe4QyHLIS/openapi.json