Company Hiring Radar — Evidence-Backed Public Hiring Research

Turn buyer-supplied Greenhouse, Lever, and Ashby board tokens into review-ready public hiring observations. For every unique board, the Actor returns the currently exposed role payload, function and location breakdowns, observable posting recency, source evidence, stable IDs, confidence reasons, material data gaps, and a conservative next action.

Open postings are useful research evidence. They do not by themselves prove headcount growth, a hiring budget, business expansion, purchase intent, a filled role, or permission to contact anyone. This Actor keeps that boundary in the data instead of hiding it in a disclaimer.

What you get

• An observation plus its limits, not a sales verdict. Total open roles and a backward-compatible activity band, with the explicit statement that it is derived only from current posting count.
• Roles by function — sales, marketing, engineering, product, leadership, data, ops, people, finance, support, legal.
• Observable recency — how many roles carry a parseable source timestamp inside the selected window, plus the timestamp basis and coverage count.
• Remote share and a full by-location breakdown.
• Keyword highlights — surface only the roles you care about (e.g. sales, growth) in matchedRoles.
• The full normalized role list (title, function, location, remote, posted date, apply URL) — same shape across every provider.
• Decision fields — stable entity/observation/event IDs, evidence, freshness, coverage, confidence, gaps, recommended action, and safeToAutomate: false.
• Run reconciliation — OUTPUT states requested, unique, processed, delivered, paid, free-failure, withheld, unprocessed, advisory, partial, budget, fatal, and replay-safe status.
• Runs on Apify: schedule it, call it from the API or MCP server, export JSON/CSV/Excel, or route results through webhooks and automation tools.

Who uses it

• Sales and account research — identify accounts with observable openings in a relevant function, then combine that fact with verified firmographic and commercial context.
• Recruiters and staffing agencies — review public role demand without scraping candidate profiles or claiming that a posting is still funded.
• Market and portfolio researchers — compare current public role mix across a buyer-defined watchlist while retaining the source and observation time.
• Competitive intelligence — inspect which functions appear in a competitor's public ATS payload, with classification and timestamp limitations visible.
• Agencies and consultants — enrich a CRM or research queue with evidence-backed talking points that still require human qualification.

The Actor does not replace a full labor-market dataset, HRIS, or commercial-intent platform. It packages one narrow, auditable source class — public ATS boards selected by the buyer — into a consistent record that can be joined to those systems.

Supported job boards

Greenhouse, Lever, and Ashby are supported. Give the token (the board slug in its careers URL) prefixed by the provider: greenhouse:stripe, lever:spotify, ashby:ramp. This selects an exact board endpoint; it does not independently prove that the board belongs to the company you had in mind.

A bare token (stripe) probes all three providers and, if more than one has a real board under that exact token, picks the one with the most open roles. A token is not a company — real example, live-verified: the bare token pulse is a genuine, active board on two unrelated companies (Greenhouse's pulse is Pulse Healthcare, 2,615 roles; Ashby's pulse is the real intended runpulse.com, 9 roles). Picking by role count alone would silently hand you the wrong company's hiring signal. Every bare-token row instead discloses the board's own declared NAME (ownerName/ownerWebsite, straight from that ATS's own data — never independently checked, since a bare token carries no domain to check it against) and, when more than one provider matched, the other real board(s) it passed over (candidates) — read those before trusting a bare-token result. A matching name is a fact worth knowing, never proof of a matching company: juno is a genuine, live case of two real boards both named "Juno" — one a Greenhouse board hiring for student-loan roles, the other an Ashby board declaring itself at juno.travel — see Output below. Use provider:token whenever you can; it has nothing to disclose because there's nothing to guess.

Finding the token: open the company's careers page. boards.greenhouse.io/**stripe**, jobs.lever.co/**spotify**, jobs.ashbyhq.com/**ramp** — the bold part is the token.

What the pipeline actually does

1. Validate before work. companies must contain 1–100 strings. Provider prefixes, token characters, keyword lengths, integer windows, and concurrency are rejected visibly when invalid; they are not silently coerced into another request.
2. Read fixed public ATS hosts. The Actor requests only the supported Greenhouse, Lever, and Ashby public endpoints. Responses are time-bounded, content-type checked, and capped at 12 MB.
3. Validate payload shape. A 200 response with the wrong JSON structure is a source failure, not an empty hiring board. Clean 404 and unavailable-source states remain distinct.
4. Normalize observable role fields. Title, location, department, apply URL, remote marker, posting time, and timestamp basis are mapped to one shape. A keyword classifier adds a function label; it does not rewrite the employer's original fields.
5. Handle identity honestly. Explicit provider:token input selects that exact board. Bare tokens probe all three providers and retain the selected board plus alternative candidates and ATS-declared names/sites. A name match is never labeled common ownership.
6. Attach decision context. Each row receives stable IDs, source evidence, freshness, evidence coverage, confidence reasons, data gaps, a review action, and an automation safety boundary.
7. Deliver and reconcile. Successful board reports use one linked Dataset/PPE operation. The exact aggregate receipt is required. OUTPUT records what was requested, processed, delivered, paid, free, withheld, or left unprocessed.

How to run it

1. Click Try for free — no card needed on the free plan.
2. Paste ATS tokens into Companies, one per line — greenhouse:stripe, lever:spotify, ashby:ramp, or a bare token to auto-detect. Optionally add Role keywords to highlight roles you care about.
3. Press Start. Results appear in the dataset — read them in the UI, pull them from the API, or have a webhook push them onward.

Pricing and billing semantics

The active pricing model is pay per event. The exact amount shown to you depends on your Apify account tier:

Tier	Run start	Successful company-board report
Free	$0.00500	$0.00200
Bronze	$0.00475	$0.00190
Silver	$0.00450	$0.00180
Gold	$0.00425	$0.00170
Platinum	$0.00410	$0.00164
Diamond	$0.00400	$0.00160

result-found means one successfully delivered report for one unique submitted ATS board, regardless of whether that board contains 0, 10, or 500 observable roles. It does not mean one charge per job posting. The historical platform event title may still say “Job posting found”; the Dataset and runtime contract are one row and one result event per successful company-board report.

Clean not-found and source-failure rows are delivered without result-found. Duplicate equivalent inputs are reported in OUTPUT and are not processed or billed twice. The automatic run-start event may still be charged even when input or source work fails. If the budget cannot cover another result, remaining work is stopped before the next linked delivery; a free advisory is added only when work actually remains.

Input

Field	Required	What it does
companies	yes	ATS tokens, one per company. Best form is provider:token — greenhouse:stripe, lever:spotify, ashby:ramp. A bare token (stripe) auto-detects the provider. Up to 100 per run.
keywords	no	Highlight roles whose title, department or function contains any of these words. Matched roles are returned separately in matchedRoles.
newWindowDays	no	A role counts as new if first published within this many days. Default 30.
maxConcurrency	no	How many companies to check in parallel, 1–30 (default 8).

{
    "companies": [
        "greenhouse:stripe",
        "lever:spotify",
        "ashby:ramp"
    ],
    "keywords": [
        "sales",
        "marketing"
    ]
}

Output

One row per company. This is a real row from a real run, trimmed only where a list repeats. It preserves the historical compatibility fields; the additive decision, evidence, freshness and action fields documented below accompany the same row in the upgraded contract:

{
    "source": "ashby:ramp",
    "token": "ramp",
    "provider": "ashby",
    "boardUrl": "https://api.ashbyhq.com/posting-api/job-board/ramp",
    "found": true,
    "matchBasis": "explicit",
    "candidateProviderCount": null,
    "ownerName": null,
    "ownerWebsite": null,
    "candidates": [],
    "checkedAt": "2026-07-26T13:56:29.833Z",
    "signals": {
        "totalOpenRoles": 118,
        "hiringMomentum": "aggressive hiring",
        "salesHiring": 46,
        "marketingHiring": 16,
        "engineeringHiring": 30,
        "productHiring": 3,
        "leadershipHiring": 3,
        "remoteShare": 0.93,
        "newRolesLast30d": 28
    },
    "byFunction": {
        "engineering": 30,
        "operations": 6,
        "sales": 46,
        "product": 3,
        "marketing": 16,
        "finance": 5,
        "people": 4,
        "data": 1,
        "leadership": 3,
        "other": 2,
        "legal": 2
    },
    "byLocation": {
        "New York, NY (HQ)": 90,
        "Remote (Canada)": 1,
        "San Francisco, CA": 7,
        "Remote (Buenos Aires, Argentina)": 1,
        "Remote (US)": 9,
        "London": 9,
        "Remote (Sweden)": 1
    },
    "matchedKeywords": ["sales", "marketing"],
    "matchedRoles": [
        {
            "title": "GTM Systems Engineer, Salesforce",
            "location": "New York, NY (HQ)",
            "department": "Engineering",
            "function": "engineering",
            "url": "https://jobs.ashbyhq.com/ramp/ffc09fc0-7785-48db-a203-a148f62534be",
            "postedAt": "2026-07-11T20:22:52.649Z",
            "isNew": true
        },
        {
            "title": "Partner Development Representative | Accounting",
            "location": "New York, NY (HQ)",
            "department": "Sales",
            "function": "sales",
            "url": "https://jobs.ashbyhq.com/ramp/b55447c0-4adc-42eb-9ca2-f88fd44e0e5b",
            "postedAt": "2025-07-25T17:14:33.373Z",
            "isNew": false
        },
        "… 61 more matched roles, same shape"
    ],
    "roles": [
        {
            "title": "Security Engineer, Cloud",
            "location": "New York, NY (HQ)",
            "department": "Engineering",
            "function": "engineering",
            "remote": true,
            "url": "https://jobs.ashbyhq.com/ramp/34413f8d-26bf-4bbc-8ade-eb309a0e2245",
            "postedAt": "2026-04-07T17:12:35.753Z",
            "isNew": false
        },
        "… 117 more roles, same shape"
    ],
    "summary": "ramp (ashby) — 118 open roles, aggressive hiring. Top: sales 46, engineering 30, marketing 16. 93% remote, 63 match your keywords, 28 new in last 30d."
}

This is a real row from a bare-token lookup, showing what "picked by role count" actually discloses:

{
    "source": "pulse",
    "token": "pulse",
    "provider": "greenhouse",
    "boardUrl": "https://boards-api.greenhouse.io/v1/boards/pulse/jobs",
    "found": true,
    "matchBasis": "bare-token",
    "candidateProviderCount": 2,
    "ownerName": "Pulse Healthcare",
    "ownerWebsite": null,
    "candidates": [
        { "provider": "ashby", "roleCount": 9, "ownerName": "Pulse", "ownerWebsite": "https://www.runpulse.com/", "sameName": false }
    ],
    "sourceErrors": [],
    "allProvidersChecked": true,
    "checkedAt": "2026-08-04T17:13:23.292Z",
    "signals": { "totalOpenRoles": 2615, "hiringMomentum": "aggressive hiring", "salesHiring": 0, "marketingHiring": 1, "engineeringHiring": 1, "productHiring": 0, "leadershipHiring": 1, "remoteShare": 0, "newRolesLast30d": 68 },
    "summary": "pulse (greenhouse) — 2615 open roles, aggressive hiring. Top: other 2603, support 7, people 2. 0% remote, 68 new in last 30d. Board name per greenhouse: \"Pulse Healthcare\". Picked greenhouse over the other real board found under this same token by role count — it's named differently — check \"candidates\" before assuming this is the company you meant."
}

pulse the token is a real, active board on TWO unrelated companies. Greenhouse's board (2,615 roles) won on volume — but its declared name, ownerName, is honestly "Pulse Healthcare", not the runpulse.com most buyers typing "pulse" would mean, and candidates[0].sameName: false says so directly, not just by implication.

A different, just as real, live case — matching names are NOT proof of a matching company, and this Actor never claims otherwise:

{
    "source": "juno",
    "token": "juno",
    "provider": "greenhouse",
    "boardUrl": "https://boards-api.greenhouse.io/v1/boards/juno/jobs",
    "found": true,
    "matchBasis": "bare-token",
    "candidateProviderCount": 2,
    "ownerName": "Juno",
    "ownerWebsite": null,
    "candidates": [
        { "provider": "ashby", "roleCount": 0, "ownerName": "Juno", "ownerWebsite": "https://juno.travel/", "sameName": true }
    ],
    "sourceErrors": [],
    "allProvidersChecked": true,
    "checkedAt": "2026-08-04T17:44:12.288Z",
    "signals": { "totalOpenRoles": 3, "hiringMomentum": "light hiring", "salesHiring": 0, "marketingHiring": 1, "engineeringHiring": 0, "productHiring": 0, "leadershipHiring": 1, "remoteShare": 1, "newRolesLast30d": 1 },
    "summary": "juno (greenhouse) — 3 open roles, light hiring. Top: other 1, marketing 1, leadership 1. 100% remote, 1 new in last 30d. Board name per greenhouse: \"Juno\". Another real board exists under this same token, named identically to this one (\"Juno\") — a matching name is not proof of common ownership; namesakes happen. That board declares its own website as juno.travel; this one declares none — if juno.travel is not the company you meant, make sure this board is before trusting the result."
}

Both boards here are genuinely named "Juno" — candidates[0].sameName: true. This Actor has no domain to check that name against (unlike its sibling actors, a bare token carries no input domain at all), so a matching name proves nothing about ownership on its own: this could be one company, or two unrelated ones that happen to share a word — live-checked, the bare token hive is exactly this: Lever's "Hive" is an AI content-moderation company, Greenhouse's "Hive" is an unrelated European B2B SaaS company hiring account managers in Berlin and Amsterdam, and both boards declare the identical name "Hive". The one asymmetric fact this Actor DOES have — the Ashby board declares its own website, juno.travel, and the picked Greenhouse board declares none — is woven straight into summary instead of left sitting in a field nobody reads. Never read sameName: true as "same company confirmed": it is a fact about the NAME, stated plainly, with the honest limits attached.

Field	What it means
found	false means no public board was found on the given/detected provider; the row explains why and is not billed
provider / boardUrl	Which ATS answered, and the exact API endpoint read
matchBasis	"explicit" — you named the provider yourself (greenhouse:stripe), nothing to disclose. "bare-token" — the provider was auto-probed; ownerName/ownerWebsite/candidates below tell you what was actually found.
candidateProviderCount	Bare-token only: how many providers had a real board under this exact token — regardless of whether every provider could actually be reached, see allProvidersChecked. null for matchBasis: "explicit".
ownerName / ownerWebsite	Bare-token only: the picked board's own declared NAME (and website, Ashby only) — straight from that ATS's own data, not independently checked against anything. null when the ATS exposed nothing usable.
candidates	Bare-token only, when more than one provider matched: the other real board(s) under this token that were NOT picked, each with its own provider, roleCount, ownerName, ownerWebsite, and sameName — true when its declared name matches the picked board's exactly (a FACT about the name only — see the juno case above for why this is never "same owner"), false when the name is different (the pulse case above), null when the comparison couldn't be made at all (at least one side's name couldn't be read).
sourceErrors	Bare-token only: which providers, if any, could not even be reached during this probe (timeout/5xx) — distinct from a provider cleanly returning "no board." Empty when every provider in the probe was reached.
allProvidersChecked	false when sourceErrors is non-empty — meaning fewer providers were actually checked than candidateProviderCount might suggest, so a differently-owned board on the unreached provider, if one exists, would not have been caught. Read sourceErrors for which provider and why.
signals.totalOpenRoles	Count of open roles right now
signals.hiringMomentum	Plain-English label derived from totalOpenRoles — light / active / strong / aggressive hiring
signals.remoteShare	Share of roles the ATS marks remote, 0–1
signals.newRolesLast{N}d	Roles first published within the configured window
byFunction / byLocation	Full breakdown of every open role
matchedRoles	Roles whose title, department or function contains one of your keywords
roles	The full normalized role list — same shape across every provider
summary	Human-readable one-liner

Additive decision contract

The historical fields above remain available for backward compatibility. Every candidate result also adds:

Field	Decision meaning
entityId	Stable hash-based ID for the selected provider and token. Use it to join observations across runs.
observationId	Stable ID for this board observation at this observation time.
eventId	Stable ID for the resulting hiring-observation, clean-negative, or unavailable-source event.
observedAt / freshness	When the source observation was made and its age at delivery. This is not the posting date.
evidence[]	Source-scoped records with evidence ID, provider, requested/final URL, retrieval time, HTTP status, bytes when available, and what the response supports.
evidenceCoverage	A 0–100 completeness indicator for this Actor's expected evidence path, not market coverage or accuracy.
confidence.score / level	Confidence in the narrow board observation and identity path. It is not confidence that the company will buy, grow, or fill the roles.
confidence.reasons[]	Human-readable reasons behind the score, including explicit versus bare-token selection and incomplete provider coverage.
dataGaps[]	Material facts that remain unknown: ownership, commercial context, posting status, provider field coverage, or missing ATS checks.
recommendedAction	A conservative review step tailored to the identity and source state.
safeToAutomate	Always false. A public hiring observation must not trigger outreach, scoring, or an account action without review and independent context.
signalInterpretation	Machine-readable separation between what was observed and what is not proven.

The old signals.hiringMomentum field remains because existing integrations may depend on it. It is a deterministic band based only on the number of currently observable roles: 0, 1–5, 6–20, 21–60, or more than 60. Read it as an activity band, not proof that hiring is accelerating. A single observation cannot measure momentum over time; schedule repeated runs and compare stable entities if you need a change series.

Timestamp and “new role” semantics

The dynamic signals.newRolesLast{N}d field counts only roles with a parseable timestamp inside the configured window. The supporting fields make the denominator visible:

• signals.timestampedRoleCount — roles with a usable source timestamp;
• signals.newRoleCountBasis — roles_with_observable_posting_timestamp;
• roles[].postedAtBasis — first_published, updated_at_fallback, created_at, published_at, or unavailable.

Greenhouse may expose first_published; when it does not, the compatibility adapter falls back to updated_at and says so. Lever uses createdAt; Ashby uses publishedAt. Therefore a role marked isNew: true means its observable source timestamp is inside the window — not necessarily that the requisition was first approved or funded then.

Run-level OUTPUT

The default Key-Value Store record named OUTPUT is the authoritative run reconciliation object. Typical complete-run shape:

{
    "status": "COMPLETE",
    "requestedCompanyCount": 3,
    "uniqueCompanyCount": 3,
    "duplicateInputCount": 0,
    "processedCompanyCount": 3,
    "confirmedDeliveredCompanyCount": 3,
    "paidCompanyCount": 3,
    "freeFailureCompanyCount": 0,
    "withheldCompanyCount": 0,
    "unprocessedCompanyCount": 0,
    "advisoryRowCount": 0,
    "partial": false,
    "budgetStopped": false,
    "replaySafe": true,
    "fatalError": null
}

This object is a contract example; counts describe the shown three-board input. The live canary receipt in this Store version is the authority for current production behavior. If replaySafe is false, inspect Dataset items and charge events before retrying: a linked delivery may have reached storage even though its receipt was ambiguous.

Failure and recovery matrix

State	Dataset behavior	Billing behavior	Recommended recovery
Clean 404 / no board	One found:false row with a corrective hint	No result-found event	Check provider and token; try another supported ATS
Timeout, 403, 429, 5xx, wrong content type, oversized or malformed payload	One source-unavailable row when free delivery succeeds	No result-found event	Retry later; do not convert it into “not hiring”
Bare token finds multiple boards	One paid selected-board row plus all candidate disclosures	One successful company-report event	Verify identity; prefer explicit provider:token next time
Budget cannot cover another result	Remaining paid work stops before linked delivery; advisory only if work remains	No next result charge	Raise the cap only if you still need the remaining boards
Linked Dataset/PPE receipt is not exact	Run fails, replaySafe:false	State may be ambiguous	Inspect Dataset, OUTPUT, and charge events before any retry
Pricing cannot be read or result event is not billable	Paid work is refused	Run-start may already be charged	Correct platform pricing; do not retry unchanged

Integration patterns

Apify API

curl -X POST "https://api.apify.com/v2/acts/zinin~company-hiring-radar/runs?token=YOUR_APIFY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "companies": ["greenhouse:stripe", "lever:spotify", "ashby:ramp"],
    "keywords": ["sales", "security"],
    "newWindowDays": 30,
    "maxConcurrency": 3
  }'

The token in this example is your Apify platform token, not an ATS credential. Do not paste it into a public document or client-side application.

JavaScript client

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const run = await client.actor('zinin/company-hiring-radar').call({
    companies: ['greenhouse:stripe', 'lever:spotify'],
    keywords: ['sales', 'marketing'],
    newWindowDays: 30,
    maxConcurrency: 2,
});

const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });
const output = await client.keyValueStore(run.defaultKeyValueStoreId).getRecord('OUTPUT');
console.log({ items, reconciliation: output?.value });

Python client

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("zinin/company-hiring-radar").call(run_input={
    "companies": ["greenhouse:stripe", "lever:spotify"],
    "keywords": ["sales", "marketing"],
    "newWindowDays": 30,
    "maxConcurrency": 2,
})
rows = list(client.dataset(run["defaultDatasetId"]).iterate_items(clean=True))
output = client.key_value_store(run["defaultKeyValueStoreId"]).get_record("OUTPUT")

CRM, spreadsheet, and webhook use

• Join rows to your own account table with entityId, while retaining the original input in source.
• Keep evidence, confidence, dataGaps, and recommendedAction together; dropping them turns a bounded observation into an overclaim.
• Use matchedRoles for a human research queue, not an automated outreach trigger.
• On scheduled runs, compare observations with the same entityId. The Actor does not maintain a hidden baseline or claim a change unless your workflow calculates one from stored observations.
• Gate downstream automation on OUTPUT.status === "COMPLETE", OUTPUT.replaySafe === true, and human review. safeToAutomate remains false at row level.

Privacy, security, and responsible use

The Actor reads public organization-level job-board endpoints. It does not log into an ATS, access applicant records, scrape resumes, contact candidates, or request private recruiter data. Inputs contain ATS board tokens and optional role keywords; outputs may contain public job titles, locations, departments, and apply URLs exposed by the employer's board.

Use the data for lawful research and respect applicable terms, privacy obligations, anti-discrimination rules, and outreach requirements. A role listing does not establish an individual's employment, protected characteristic, or consent. Do not use this Actor to make employment, credit, housing, insurance, legal, or similarly consequential decisions about a person.

Source requests are restricted to fixed Greenhouse, Lever, and Ashby hosts derived from bounded tokens. Response type and size are checked. Error output is classified for recovery and is not a license to expose credentials or private network data. No ATS API key is required or accepted.

Known limits

• Only Greenhouse, Lever, and Ashby public board formats are supported.
• The buyer must supply a valid board token; this is not a company-discovery crawler.
• Explicit provider/token selection chooses a board but does not independently verify corporate ownership.
• Bare-token auto-detection is inherently ambiguous. Alternative boards, names, and available declared sites are evidence for review, not an identity verdict.
• Public boards can omit, revise, close, duplicate, or backdate postings. A posting can remain visible after the underlying process changes.
• Function labels are heuristic keyword classifications. byFunction may differ from the employer's organizational taxonomy.
• Remote detection depends on provider flags and visible text. Hybrid, region-limited, or negotiable arrangements may not normalize cleanly.
• One run is a current observation, not a trend. Store and compare repeated observations to measure change.
• No field proves headcount, filled roles, budget, expansion, financial health, purchase intent, or contact permission.

Related tools

Related tools for adjacent workflows in B2B lead generation and data enrichment, jobs and hiring.

Actor	What it does
Job Postings Aggregator	Pair it in the jobs and hiring workflow: Pull every open role from a company's public applicant-tracking system (Greenhouse, Lever, Ashby) and...
Intent Signal Aggregator	Pair it in the B2B lead generation and data enrichment workflow: Is this company in-market right now? Combines public hiring activity (Greenhouse, Lever, Ashby) and recent...
B2B Lead Enricher	Pair it in the B2B lead generation and data enrichment workflow: Turn a list of company websites into sales-qualified lead cards: detected tech stack, a rough revenue...
Counterparty Risk Rollup — Sanctions, Courts, Registry, Hiring	Pair it in the B2B lead generation and data enrichment workflow: One call, one row per counterparty: sanctions screening (OFAC + EU), legal-entity registry (GLEIF),...
Layoff Tracker	Pair it in the jobs and hiring workflow: Track recent tech layoffs by company name or sector (e.g. "fintech", "AI") straight from Google News — a...

FAQ

Is this legal? The Actor reads unauthenticated public job-board endpoints and does not access applicant records. Whether a particular collection, storage, combination, or use is lawful depends on your jurisdiction, purpose, contracts, and obligations. This documentation is not legal advice.

Does it need proxies or an API key for the ATS? No. The supported endpoints are public and unauthenticated. They can still change, rate-limit, fail, or return incomplete fields; those states are surfaced rather than called a clean negative.

How is a role's function decided? By a keyword classifier over the title and department (e.g. "Account Executive" → sales, "SRE" → engineering). Where a provider gives a department it's kept as-is; roles that match no rule fall into other.

What if a company isn't found? You get found: false with a hint. A clean "no board" (wrong token, or an ATS not yet supported) reads differently from a source hiccup (the ATS API timed out or rate-limited mid-check) — the error text says which one happened, so you know whether to fix the token or just retry. A source hiccup can also happen on a bare token that DID find a board on another provider — see sourceErrors/allProvidersChecked below, checked even on a found: true row.

I used a bare token and got a board — is that definitely my company? Not necessarily, and this Actor has no way to be sure either — a bare token carries no domain to check a name against, so the most it can ever tell you is whether the board's declared NAME matches another real board under the same token, never whether the two are the same company. pulse is the clean case: candidates[].sameName: false — Pulse Healthcare (Greenhouse) and the unrelated runpulse.com (Ashby) are named differently, worth checking before you trust the pick. juno is the harder, equally real case: candidates[].sameName: true — a student-loan Greenhouse board and a travel-industry Ashby board (juno.travel) are BOTH genuinely named "Juno". hive, echo, tempo, kit, glow and onyx also live-checked with sameName: true — some may be the same company, some may be namesakes like juno; this Actor cannot tell the difference from a name alone, and does not pretend to. Check candidates either way: true means named identically (read the caveat, never "same company"), false means named differently (the caution case), null means it couldn't be checked at all. Use provider:token (e.g. ashby:pulse) whenever you know it — it names the board yourself, so there's nothing left to guess.

Which company should I look up? A company whose public careers link clearly uses Greenhouse, Lever, or Ashby. Prefer copying the exact provider and board token from that link. Other ATS providers are not currently supported.

Can I call it from an AI agent? Yes — standard Apify Actor, callable from the Apify API, the SDK, or the Apify MCP server.

What this is NOT. It does not scrape resumes, contact candidates, or read anything behind a login. It reads one public signal — a company's own open-roles feed — and classifies it.

Found a wrong result, or need an ATS provider we don't support yet? Open an issue on this Actor's page.

---

Built by zinin. Questions? Telegram @timzinin.