# Workable Jobs API - Search 66 Boards, No Company List (`deadwood_data_solutions/workable-jobs-api`) Actor Query an index of 66 verified Workable boards — 1,116 open roles — with no account slugs of your own. Filter by title, location, remote and posting date, or name your own boards. Deduped so scheduled runs return only new roles. Free sync to Notion, HubSpot or Airtable. - **URL**: https://apify.com/deadwood\_data\_solutions/workable-jobs-api.md - **Developed by:** [K O](https://apify.com/deadwood_data_solutions) (community) - **Categories:** Jobs, Lead generation, Automation - **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: No ratings yet ## Pricing from $2.00 / 1,000 job records This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event ## What's an Apify Actor? Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows. 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. Actors are written with capital "A". ## 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. The best way to integrate Actors is as follows. - **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use). - **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`. - **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`. - **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`. - **Any other language** — the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README ## Workable Jobs Scraper — Description, Requirements and Benefits, Split Out **The only one of our ATS board scrapers that returns a posting's requirements and benefits as their own fields, instead of folding everything into one description blob.** Turn on `includeDescription` and you get `descriptionHtml`, `requirementsHtml` and `benefitsHtml` back separately, each pulled from Workable's per-job detail endpoint. ### Pain points - Workable's public widget API lists jobs, but the full description, requirements and benefits live on a separate per-job detail endpoint you have to call individually — there's no bulk detail fetch. - Multi-country postings need flattening; most scrapers keep only one location string and lose the rest. - Most job scrapers that do fetch the full posting body hand it back as one undifferentiated blob — you have to re-parse it yourself if you actually want "requirements" separate from "description." - Watching a list of accounts for genuinely new roles means storing what you already pulled and diffing every run yourself. ### What we solve - **Three-way structured content.** With `includeDescription` on, each posting's detail call is split into `descriptionHtml`, `requirementsHtml` and `benefitsHtml` — three fields, not one blob. - **Deduplicated country coverage.** `countries` is a deduplicated array of every country a posting is open to, built from Workable's per-location list. - **Multi-board in one run.** Pass a list of `companies`; an account slug that fails or was renamed is skipped with a logged warning, not a fatal error — the rest of your list still comes back. - **Dedup built in.** `onlyNewSinceLastRun` (default on) persists the last 20,000 posting ids seen, so a recurring schedule only bills for postings that are genuinely new. ### Who uses it Recruiters and sourcers, job-board and ATS aggregators, sales teams tracking a target account's hiring, labor-market analysts, and anyone building a "new roles at companies I follow" alert. ### Search every board we know - no company list at all Turn on **Search every board we know** and you do not supply companies, slugs or bundles. The run queries our index of **66 verified workable boards** - **1,116 open roles** at the last check on 2026-08-24 - and applies your title, location and remote filters across all of them. Ask it things a company list cannot answer: - every remote senior backend role posted this week - everything matching "machine learning" across every board in the index - new postings only, across the whole index, on a daily schedule | ATS | Boards | |---|---:| | workable | 66 | Every board in the index answered its ATS with at least one open role when the index was built. Boards are fetched most-active first and capped by **Maximum boards to search** (default 200), because each board is one request. The index is rebuilt on a refresh sweep; a board that stops answering three sweeps running is retired from it, and anything that fails during your run is reported in `FAILED_TARGETS` rather than silently shrinking your results. ### Input | Field | What it does | |---|---| | `searchIndex` | **No company list at all.** Query every board in the shipped index and apply your filters across all of them. See the section above. | | `maxBoards` | Only used with `searchIndex`. Each board is one request, so this caps run length. Boards are searched most-active first. | | `companies` | One or more Workable account slugs — the slug in `apply.workable.com/` (e.g. `walter-careers`, `welcome-jobs`). | | `maxPerCompany` | Stop after this many jobs from each board, so one large employer cannot fill the whole result. Recommended with index search. Empty = no cap. | | `titleIncludes` | Keep only jobs whose title contains one of these keywords (case-insensitive). Empty = all. Applied **before** billing. | | `locationIncludes` | Keep only jobs whose location contains one of these keywords. Empty = all. Applied **before** billing. | | `remoteOnly` | Keep only remote-flagged roles (or locations mentioning remote). Applied **before** billing. | | `postedWithinDays` | Keep only postings published in the last N days — `7` gives you this week's roles. Postings on boards that publish no date are left out, because they cannot be shown to be recent. Applied **before** billing. | | `includeDescription` | Fetch each posting's full HTML description, requirements and benefits (one extra request per job). Off by default for lean records. | | `onlyNewSinceLastRun` | Recommended for schedules — skips jobs already returned by a previous run, so you're only charged for genuinely new postings. Default `true`. | | `maxItems` | Stop after this many normalized records. | | `syncEnabled` | Optional, off by default. Also send each new job straight to a connected app — see [Sync](#sync-to-your-crm-notion-hubspot-airtable-or-supabase-optional) below. | | `syncDestination`, `syncWriteTool`, `syncFieldMap`, `syncExtraArgs` | Only used when `syncEnabled` is on. | ### Output | Field | Description | |---|---| | `jobId` | Workable's posting shortcode. | | `code` | Employer-assigned requisition code, when set. | | `company` | Account display name (falls back to the slug you queried). | | `title` | Job title. | | `location` | Built from city/state/country, or `"Remote"` when telecommuting and no location is set. | | `countries` | **Array**, deduplicated — every country this posting is open to. | | `remote` | Boolean, from Workable's `telecommuting` flag. | | `department` | Department, when Workable provides one. | | `employmentType` | e.g. Full-time. | | `publishedOn` | Publish date. | | `createdAt` | Creation date. | | `url` | Public posting URL. | | `applicationUrl` | Direct apply-form URL. | | `descriptionHtml` | Full HTML description — **only when `includeDescription` is on**; otherwise `null`. | | `requirementsHtml` | Requirements, as its own HTML field — **only when `includeDescription` is on**; otherwise `null`. | | `benefitsHtml` | Benefits, as its own HTML field — **only when `includeDescription` is on**; otherwise `null`. | | `source` | Always `"Workable"`. | | `jobFunction` | Workable's job-function tag, where the account sets one. | | `industry` | Workable's industry tag, where the account sets one. | | `experienceLevel` | Workable's experience tag, where the account sets one. | | `education` | Workable's education tag, where the account sets one. | | `workplace` | Workable's workplace label, from the job detail. | | `salaryMin` / `salaryMax` | Pay range as plain numbers, so you can sort and filter on it. `null` when the posting does not state pay — never a guess. | | `salaryCurrency` | ISO code (`USD`, `EUR`, `GBP`, …) where the posting makes it clear. | | `salaryInterval` | `YEAR`, `MONTH`, `WEEK`, `DAY` or `HOUR`. | | `salaryText` | The pay exactly as the posting worded it, kept so you can audit the parse. | | `salarySource` | `ats` when the board published structured pay, `ats-summary` or `description` when it was read out of the posting text. `null` when no pay was found. | | `cityDerived` / `regionDerived` / `countryDerived` / `countryCodeDerived` | The location string split into parts, so "Austin, TX" is filterable by state and country instead of by substring. | | `locationType` | `REMOTE`, `HYBRID` or `ONSITE`. | | `seniorityLevel` | `INTERN`, `JUNIOR`, `SENIOR`, `STAFF`, `PRINCIPAL`, `MANAGER`, `DIRECTOR`, `VP` or `EXECUTIVE`, read from the title. `null` when the title carries no signal. | | `employmentTypeNormalized` | `FULL_TIME`, `PART_TIME`, `CONTRACT`, `INTERN`, `APPRENTICESHIP` or `VOLUNTEER` — one enum across every ATS, so records are comparable. | | `daysSincePosted` | Whole days since the posting went live, precomputed. | | `organizationUrl` | The public careers board this posting came from. | **Pay coverage.** Workable's job list carries no pay field, so pay can only be read from the job detail — meaning `salaryMin`/`salaryMax` populate **only when `includeDescription` is on**, and only for postings that state pay in the text. This is a real record, captured live from the `walter-careers` account on 08/21/2026 — not a placeholder: ```json { "jobId": "E53A5AB739", "code": null, "company": "Walter", "title": "Talent Sourcer", "location": "Brazil", "countries": [ "Brazil" ], "remote": true, "department": "Arc Dev", "employmentType": "Full-time", "publishedOn": "2026-05-08", "createdAt": "2026-05-08", "url": "https://apply.workable.com/j/E53A5AB739", "applicationUrl": "https://apply.workable.com/j/E53A5AB739/apply", "descriptionHtml": "

Talent Sourcer @ Arc.Dev

Job Title: Talent Sourcer

Locatio...", "requirementsHtml": "