Workable Jobs API.
A developer’s reference. Workable ships a Job Board API, but every customer’s API key is private to their account - aggregation across customers isn’t supported first-party. Here is what the actual data path looks like and when reaching for a unified jobs API removes the per-tenant key juggle.
On this page
The short answer
Workable has two APIs. The Job Board API returns the public postings for one Workable customer account - title, location, employment type, posting timestamp, structured description. The main Workable API is the full ATS surface - OAuth- scoped per account, covers candidates, applications, scheduling, webhooks. Both are real, both are useful, and both are scoped to one Workable customer at a time.
Neither solves the multi-tenant aggregation problem. Workable does not issue a key that returns postings across the Workable customer base. To read postings across many Workable-using companies, your options are: per-customer API keys (each customer mints you one), per-customer scrapers against apply.workable.com (HTML and JSON varies by plan tier), or a unified jobs API that handles the integration centrally.
The Job Board API at a glance
| Aspect | Value |
|---|---|
| Auth | Per-account API key (private to the Workable customer) |
| Scope | Public postings for one customer at a time |
| Format | JSON, stable per customer |
| Cost | Bundled with Workable plan |
| Cross-customer | Not supported |
Why per-account keys block aggregation
The Workable API model treats each customer’s data as a private surface that the customer themselves owns. The API key is provisioned inside the customer’s Workable account and gives access only to that account’s data. There is no multi-tenant aggregation key, no “list all Workable customers” endpoint, and no developer program that grants cross-customer read access.
This is by design - it’s the same pattern as Workable’s peers in the modern ATS category (Greenhouse’s Harvest API is similar). The tradeoff is clean per-customer integrations at the cost of an aggregation gap that has to be filled outside Workable.
Why scraping breaks at scale
Discovery. Workable doesn’t publish a customer directory. The apply.workable.com/company URL pattern makes discovery technically possible (you crawl from a list of known slugs), but maintaining that list is an ongoing job.
Plan-tier variance. Workable’s rendered shape varies by plan tier - free Workable customers get a slightly different careers page than paid customers, which means per-customer scraper configs have to handle multiple shapes.
Rate limits. Per-domain rate limits and CDN protection apply. Scraping many customer subdomains from one IP gets blocked quickly without IP rotation and polite cadences.
When to use a unified API instead
If you have a Workable customer relationship - ask them to mint you a Job Board API key and integrate directly. That is the supported per-customer path.
If you need Workable postings across many customers - for a job board, sales-trigger workflow, or hiring-signal intent product - JobsPipe indexes every public Workable careers site and serves it alongside Workday, Greenhouse, Lever, BambooHR, Paycom, and 30+ other sources in one normalized JSON schema. Free tier covers 5,000 requests/month with no per-customer keys to juggle.
FAQ
Does Workable have a public jobs API?+
Yes, with a catch. Workable ships a Job Board API that returns public postings for a single customer - but every Workable customer's API key is private to their own account. There is no first-party endpoint that exposes jobs across many Workable customers at once. The 'public API' framing in Workable's documentation refers to public-vs-internal data per customer, not to multi-tenant aggregation.
What does the Workable Job Board API return?+
Per-account public openings with title, location, employment type, department, posted timestamp, and a structured description. The shape is clean and stable per customer, but the key holder is the customer themselves - third parties need each customer to grant access individually.
How are Workable careers pages addressed?+
Workable customer careers pages live on apply.workable.com/<company> subdomains by default, or on customer-owned domains via Workable embeds. The subdomain pattern makes discovery somewhat possible (you can crawl from a directory of known apply.workable.com paths) but Workable does not publish a customer list.
Can I scrape apply.workable.com?+
Yes per customer. Each customer is a separate config, and Workable's HTML/JSON shape varies by plan tier (free vs paid Workable plans render slightly differently). Ongoing maintenance is the recurring cost.
How does JobsPipe handle Workable?+
JobsPipe indexes every public Workable careers page and normalizes the data into the same JSON schema as our 30+ other sources. No per-customer key, no scraper config per tenant. Free tier covers 5,000 requests/month with no credit card.
What's the difference between Workable's Job Board API and the main Workable API?+
The Job Board API is read-only and scoped to public postings for one customer account. The main Workable API is the full ATS surface - OAuth-scoped per account, covers candidates, applications, scheduling, and webhooks. Different purposes, both per-customer-scoped. For aggregating postings across customers neither is the right shape.
Does JobsPipe access private or internal Workable data?+
No. JobsPipe indexes only jobs marked public by the Workable customer. Internal postings, draft postings, and candidate/applicant data are out of scope.
How fresh is Workable data on JobsPipe?+
Public Workable careers pages are re-crawled at least every 24 hours. New postings appear within that window.
Every public Workable careers site, one endpoint. No per-customer key juggle.
Get a free API key