Job Posting Tech Signals — Greenhouse & Lever

Job-text technology evidence for research, not a generic job aggregator or purchasing-intent classifier.

Get source-linked signals when your selected companies' current public job descriptions expressly mention a technology. Search AWS, Kubernetes, Terraform, Postgres, Snowflake, React, and your own exact terms. Each output is one distinct posting/technology pair with a concise source excerpt and the original posting URL.

What this Actor does

• Reads the officially documented public Greenhouse Job Board API and Lever Postings API v0, for company/board identifiers you provide.
• Scans only description/body/requirements text; it does not infer technology from the job title, URLs, metadata tags, company marketing language, or related websites.
• Returns the company label, ATS provider, board, job title, job ID, publication date if explicitly supplied, matching technology, short snippet, posting URL, and company website only when the supplied origin is corroborated by the posting URL returned by the official ATS API.
• Deduplicates identical provider/job ID/technology combinations and limits results, requests, fetch sizes and retries.
• Does not provide worldwide company search, board discovery, applicant details, private postings, inferred technology adoption, vendor relationships, customer lists or purchase intent.
• Does not enable proxies or bypass blocked endpoints. All reads use public HTTPS GETs. No applicant forms are submitted.

Input

Enter your terms, identify one or more public boards, and optionally restrict publication dates or results. A Greenhouse board identifier is the final path segment in the public board URL, such as discord from job-boards.greenhouse.io/discord. A Lever site identifier is the final path segment in jobs.lever.co/field-ai. Lever EU users can add region: eu.

Example input (also at examples/input.json):

{
  "technologyTerms": ["AWS", "Kubernetes", "Terraform", "Python"],
  "boards": [
    { "provider": "greenhouse", "board": "discord", "company": "Discord" },
    { "provider": "lever", "board": "field-ai", "company": "FieldAI" }
  ],
  "maxResults": 12,
  "maxJobsPerBoard": 12,
  "requestDelayMs": 1100
}

No ATS board list is bundled. The sample input covers only two known public ATS boards, not arbitrary companies.

Use dateFrom / dateTo formatted YYYY-MM-DD to restrict publication dates; undated posts are excluded when this filter is used. Greenhouse's first_published is preferred; it can be obtained from the per-job GET when not present in the list. Lever v0 typically omits first-published timestamps: those results report null instead of falsely labeling createdAt or updated_at as publication date.

The company value is a user-supplied label or board identifier, not a verified legal entity name. For optional website verification, provide a company's HTTPS homepage as website in the board object. The supplied origin must exactly match the non-ATS origin of the job URL returned by the official ATS API. Arbitrary homepage backlinks are NOT proof of company ownership, and no arbitrary websites are fetched. If the job is hosted on Greenhouse or Lever, or corroboration is unavailable, this field stays null. We do not guess domains from company names.

Output and evidence

Default Dataset has one object per unique detected posting/technology pair. The run summary is in default Key-value Store at RUN_SUMMARY and reports request count, downloaded bytes, duration, inspected jobs, duplicate suppression, actual SDK charge counts, budget termination and failures. Each row has an observedAt timestamp; this is separate from the publication date.

Example output (illustrative, not a claim about any named company):

{
  "company": "Example Ltd",
  "provider": "greenhouse",
  "boardIdentifier": "example",
  "jobTitle": "Platform Engineer",
  "jobId": "123456",
  "publishedAt": "2026-09-24T09:00:00.000Z",
  "matchedTechnology": "AWS",
  "evidenceSnippet": "Experience deploying services on AWS and Kubernetes.",
  "jobUrl": "https://job-boards.greenhouse.io/example/jobs/123456",
  "verifiedCompanyWebsite": null,
  "signalType": "explicit_job_description_mention",
  "interpretation": "Job text mentions this technology; not verified usage, vendor-customer status or purchase intent."
}

A posting may mention multiple technologies, generating one evidence-backed result per technology. An AWS mention does not establish that the company is an AWS customer, intends to purchase AWS, or has approved a budget.

Keyword matching is conservative: whole-token boundaries, punctuation-aware matches, HTML stripping, URLs removed, and case-sensitive treatment for ambiguity-prone short terms such as Go, R, AI and React. This is evidence-based term matching, not a semantic inference engine. A company could list future interests, former technologies or "nice-to-have" skills, so human review of the linked posting is essential.

Pricing and resource use

Price: USD 0.002 per unique output row — USD 2 per 1,000 technology signals.

The sole paid event is tech-signal. No startup fee and no additional synthetic dataset-item event are configured. A minimum run spending limit of USD 0.002 is a budget setting, not an upfront fee. A zero-match run produces zero charge events. One matched job with AWS + Kubernetes creates two billable events, not one. No result means no tech-signal event. Duplicate posts or failed/unmatched records are not charged as tech-signal events. The event price shown in the Store pricing panel is authoritative. The run stops when the SDK reports that the user spending limit is reached.

Indicative event charges at USD 0.002 each: 10 results = USD 0.02; 100 results = USD 0.20. These are not a platform usage cost quote. Public API response sizes, selected board size and memory/time affect underlying platform compute/data cost. Greenhouse returns the full board response even when you ask to inspect only a small number of jobs. No proxy, LLM or paid data supplier is used.

Only successful pushes of unique signals are passed to the tech-signal event. RUN_SUMMARY.billableSignals counts delivered rows; RUN_SUMMARY.chargedEvents counts SDK charge receipts. Local callback counts are not represented as paid events. Owner validation runs are not customer revenue.

Sources, rights and boundaries

• Greenhouse official Job Board API: https://docs.greenhouse.io/job-board.html
• Lever official Postings API: https://github.com/lever/postings-api/blob/master/README.md
• Compliance review: docs/SOURCE_RIGHTS.md

The vendors document public GET access for published postings, primarily to display companies' own career pages. Their API documentation is not a blanket license for commercial redistribution or an assurance that every hiring organization's own conditions allow such use. This Actor never supplies full job descriptions, does not bulk export their raw feeds and always provides source attribution; you remain responsible for rights and permitted downstream use. This is a paid processing tool for boards you are authorized to analyze, not a pre-licensed company database. Use company-owned or expressly permitted sources; do not treat the technical sample as a content redistribution license. Do not use it for unlicensed resale or mass republishing of job content. Review site and provider terms for your intended board list; when rights are unclear, obtain appropriate permission. Not affiliated with or endorsed by Greenhouse or Lever.

Limits, failures and privacy

• 1–20 explicitly specified boards, 1–30 terms, max 200 signals, 300 postings inspected per board.
• 1-second minimum delay between GET attempts, 18-second per-request timeout, at most one retry for HTTP 429/503, honoring Retry-After; long cooldowns stop the board instead of retrying early. Response sizes are bounded.
• Missing/blocked boards are reported in RUN_SUMMARY without fake matches. If all boards fail, the run fails.
• No crawling of search engines, candidate profiles or application records; no anti-blocking proxy; no bulk storage of raw job descriptions.
• Individual results can change as employers edit or close postings. This is a current, best-effort snapshot, not historical archival coverage.

Local development and verification

Within the project folder:

npm install --omit=dev
npm test
npm run live

Unit tests cover false positives, HTML decoding, duplicates, dates, safe inputs, isolated failures, correct FAILED status on invalid input, spending-limit termination, and company-domain false positives. The live sample exercises two public ATS APIs with 12 posts inspected per board; details are recorded in reports/live-validation.json.

Apify local run, after installing the Apify CLI, reads input via the default Apify storage INPUT record. For cloud deployment, only deploy from this API07 folder and use the existing authenticated Apify CLI. API04 and other projects must remain untouched.

Support: Report any issue in the Actor's Apify Issues section with a board identifier, job URL, a redacted input, and an Apify run ID. Do not include any Apify API tokens or applicant data.