Workable Jobs Scraper - apply.workable.com Careers, No API Key

SOURCE COVERAGE & PRACTICAL LIMITS

Full product guide

Documentation captured from build 1.0.6. Example outputs retain their original sample context; they are not live results.

Workable jobs, clearly structured

For recruiters and job-board operators, collect public Workable careers postings in a consistent table without a Workable API key.

Coverage: Employer careers pages on Workable, rather than Workable's cross-company job-search site. One result per distinct job shortcode.

Open this Actor in Console · First run · Results · Cost · Full guide

Try this Actor

1. Use the Blueground careers-page example already shown below. Keep description enrichment off and lower the total posting cap before expanding to more companies.
2. Open the dataset for job rows, then inspect SUMMARY.boardHealth to distinguish empty boards, rate limits and companies not reached.

Read the results correctly: Remote is the employer's own flag; hybrid, on-site and structured salary are not inferred. New-postings mode records only successfully saved IDs.

Result preview

The dataset view highlights these columns:

• Company · company
• Job title · title
• Department · department
• Published employment type · employmentType
• First advertised location · location
• All advertised locations · locations

Use the original source links and the field definitions below when interpreting the results. CSV works well for flat columns; JSON preserves nested values.

Usage and pricing

Base result rate on the FREE tier: $1 per 1,000 results. The Pricing tab shows your plan's result rate and any Actor Start charge. Set a small result limit for the first run; the requested limit is not a guarantee of that many results.

Full guide

Scrape published job postings from any Workable careers page (apply.workable.com/<slug>) and get them back as flat CSV, JSON or Excel rows. Give it an account slug (blueground) or the careers-page URL (https://apply.workable.com/blueground/) and this Workable scraper returns every posting the employer has published there: job title, department, employment type, city / region / country, the employer's remote flag, published date, posting and apply links, and - when you ask for it - the full job description converted from Workable's HTML into clean plain text.

Built for recruiters, sourcers, job-board operators and anyone tracking hiring at a list of companies. It reads the public JSON endpoint behind Workable's embeddable jobs widget, so there is no API key, no login and no Workable account involved. Pass one company or a few dozen.

This Actor covers Workable careers pages only. It does not read jobs.workable.com (Workable's cross-company job search, which its robots.txt disallows), and a company that does not host its careers page on Workable cannot be scraped here.

What you get

One row per distinct job shortcode. Workable sometimes repeats a posting once per location; these variants are merged before result limits and billing. locations retains every advertised location, while city, region, country and location describe the first source variant. Fill rates below were measured on 678 source rows across three real runs on 2026-09-25; a blank means the employer left that field empty in Workable.

A SUMMARY record is written to the run's key-value store with a board-health report for every company requested (ok with jobs, empty, not-found, rate-limited, error, not-reached, each with the company name and how many postings were published and saved), which companies failed and why, the total postings published, and department and country breakdowns (top 25 of each with counts).

Input

Example output

A real row from a run with includeDetails on (description truncated here for readability):

{
  "company": "EUROPEAN DYNAMICS",
  "slug": "european-dynamics",
  "jobId": "47DDC6EF15",
  "requisitionCode": "DSE/09/26",
  "title": "DevSecOps Engineer",
  "department": "PRB",
  "employmentType": null,
  "function": null,
  "industry": "Computer Software",
  "experienceLevel": null,
  "educationLevel": null,
  "city": "Athens",
  "region": "Attica",
  "country": "Greece",
  "countryCode": "GR",
  "location": "Athens, Attica, Greece",
  "remote": true,
  "workplaceType": "Remote",
  "publishedAt": "2026-09-14",
  "createdAt": "2026-09-14",
  "url": "https://apply.workable.com/j/47DDC6EF15",
  "applyUrl": "https://apply.workable.com/j/47DDC6EF15/apply",
  "descriptionText": "We are looking for a DevSecOps Engineer to help us build, automate, secure, and operate reliable software delivery platforms ...",
  "scrapedAt": "2026-09-25T17:34:59.865Z"
}

FAQ

Where do I find a company's slug? Open the company's careers page. If it is hosted on Workable the address looks like https://apply.workable.com/<slug>/ - the slug is that path segment (blueground, european-dynamics, uni-systems). You can paste the whole URL, or a link to one of its job postings, into companies and the Actor extracts the slug. A slug with no careers page returns HTTP 404 and is reported for that company only; the rest of the run continues. The slug workable is not an account (Workable's own openings are at careers).

The company exists but I got no rows. That is a real answer, not a failure: plenty of Workable accounts resolve but currently publish zero jobs (in the accounts checked while building this Actor, more than half were in that state). The run finishes successfully, logs a warning, and the company shows up in SUMMARY.boardHealth as empty. Check the page in a browser at https://apply.workable.com/<slug>/ if you expected postings.

What exactly does "only postings new since the last run" do? With the option on, the Actor records successfully saved job IDs in the named key-value store workable-jobs-scraper-state, keyed by board (and platform where applicable). The first run has no baseline and returns matching postings up to your result and charge limits. Later runs return IDs not already saved. Prior seen IDs are retained; newly discovered jobs excluded by filters, result caps, or the charge limit are not marked seen and remain eligible for a later run. A run with nothing new succeeds with an empty dataset and a warning. The baseline is written only while this option is enabled. Runs watching the same board share its baseline, so use one schedule per board and avoid concurrent runs against that baseline.

Is the description really plain text? Yes. Workable returns descriptions as HTML. This Actor strips the tags, decodes the entities and keeps list items as - bullets. On the 335-row run with includeDetails on that produced the example above, 0 rows contained leftover HTML tags or entities; descriptions averaged about 4,700 characters.

Why is there no hybrid / on-site value, and no salary? Because the widget endpoint does not publish them. The only workplace signal it carries is the employer's boolean remote flag, so remote is that flag and workplaceType is Remote or blank - nothing is inferred from the text. There is no structured salary either; pay ranges appear inside descriptionText when the employer wrote them into the posting. No made-up columns.

How fast is it? Workable returns an entire careers page in a single request, with no pagination. Measured locally on 2026-09-25, end to end including writing the rows: the default run (18 companies, 584 postings published, 300 saved) took about 8 seconds; four companies with 43 postings took under 3 seconds; five companies with 335 postings and full descriptions took under 5 seconds. Platform runs add the time to write results over Apify Storage. After the first 25 companies in a run the Actor deliberately slows to one request every 2.5 seconds - see the limits section for why.

Data source, access and limits

• Source: the JSON endpoint behind Workable's embeddable jobs widget, https://apply.workable.com/api/v1/widget/accounts/{slug}?details=false|true. It is public but undocumented - it needs no key, login, account or cookies, but Workable does not describe it in its developer documentation, so its shape could change without notice. Only postings the employer has published on their careers page are returned.
• Crawling is allowed; training is not. https://apply.workable.com/robots.txt (read 2026-09-25) is User-agent: * / Disallow: (nothing disallowed) with Content-Signal: search=yes, ai-input=yes, ai-train=no. So: use the data for recruiting, job aggregation, market research and monitoring; do not use it to train AI models. jobs.workable.com, Workable's cross-company search, is disallowed to crawlers and this Actor never touches it.
• Rate limit. Workable's edge (Cloudflare) rate-limits this endpoint, and it is keyed to how many different pages one client asks for, not to raw request count: on 2026-09-25, 150 requests for the same careers page in five seconds went through untouched, while 50 requests for 50 different (unknown) slugs in two seconds got HTTP 429 (an HTML error page). The first three blocks that day carried retry-after: 0 and cleared within twenty seconds to five minutes. After a fourth burst inside the same hour the 429 came back with retry-after: 85836 (about 24 hours); over the following half hour that block was enforced inconsistently - some requests from the same client went through while others were refused with the same expiry - so treat a long retry-after as real. A run is one request per company, so a list of a few dozen companies is fine (30 companies in one run did not trip it); past 25 the Actor paces itself to one request every 2.5 seconds. A 429 with no retry-after is retried four times over 45 seconds; a short retry-after (up to 45 seconds) is waited out once and the request tried once more; a longer retry-after is treated as the block it is - the Actor does not retry it. Either way the run stops there, keeps what it has, writes the board-health report, and lists the companies it did not reach in SUMMARY.boardHealth as not-reached (the refused one as rate-limited, with retryAfterSec) so you can re-run just those later. Spreading scheduled runs apart helps, and so does not passing long lists of guessed slugs - unknown slugs count too. Apify runs share outbound IPs with other users, so a block caused by someone else's traffic is possible; it shows up as rate-limited in the board-health report, never as "no jobs".
• remote is the employer's flag, not an inference. A role that is remote only in its description text reads false.
• Everything else is passed through as published. Titles, departments, functions, industries, levels, locations and dates come from the employer's own Workable data, including its gaps - the fill rates above are what employers actually fill in.
• No candidate or application data is extracted. Every row describes a job posting, not a person: there is no recruiter name, email or phone field, and none is inferred. descriptionText is the employer's own published description reproduced as text. Nothing is collected from candidates or applications.
• Failures are explicit. Companies that 404 or error are named in the log and in SUMMARY.failedSources, and the run still saves everything from the companies that worked. If every company that was fetched fails, the run fails with a message naming the likely cause instead of returning an empty dataset that looks like "no jobs". The SUMMARY record, with the board-health report, is written before the run fails, so you can still see which companies were refused and which were never reached.
• Billing: this Actor is billed per result on Apify - the current rate is on the Pricing tab of this Actor's page. There is nothing else to buy; the data source itself needs no key.
• Not affiliated with Workable. Workable is a trademark of Workable Software Limited; this Actor is an independent tool that reads publicly available careers-page data.

Saved rows and run charge limits

The Actor writes results one at a time and stops when Apify reports the run charge limit. SUMMARY.stoppedOnChargeLimit distinguishes that stop from an empty source. Saved-row counts include only rows accepted by the dataset. For change detection, prior seen IDs are retained and newly discovered IDs enter the baseline only after their row is saved; rows excluded by a result or charge cap remain eligible for a later run. Avoid concurrent monitor runs sharing the same named baseline store.

Help with your run

Open the Issues tab on this Actor with the run URL, the input field that caused trouble and what you expected to receive. Remove API keys and private information before posting.

Explore more Mayd-It Actors

Understand your run

Open Run report in the run’s Output tab for saved-record counts, reported source issues and limits, and suggested next steps. Use CSV export to take the saved results into a spreadsheet. The existing JSON results and detailed machine-readable summary remain available.

The report reflects this run’s recorded coverage. A successful run or a saved result does not establish that every possible source record was collected.