Workable API Guide: Rate Limits, Scopes, Endpoints (2026)

With a standard account token, the Workable API gives you ten requests every ten seconds. That number shapes everything you build on it.

This guide covers the documented facts developers search for: rate limits, the token model, pagination, and what the public SPI v3 spec supports. It adds the engineering patterns real teams use around those limits, sourced from production GitHub repositories.

It ends with a comparison between the Workable and 100Hires APIs. Full disclosure: 100Hires builds a competing ATS with its own API.

Claims about Workable's API link to its live documentation or public artifacts so you can verify them; the few observations from our own experience are labeled as exactly that.

Workable API quick reference

What is the Workable API rate limit?

The documented numbers first. Account tokens get 10 requests per 10 seconds. OAuth 2.0 and partner tokens get 50 per 10 seconds. Exceeding either returns HTTP 429, and every response carries X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset headers.

The source is Workable's own rate limits reference, and the same figures appear word for word in two help center articles. The docs are clear on the numbers.

The reviewed public documentation describes no process for raising the limit within a token class. The only documented lever is switching class: OAuth and partner tokens have five times the allowance, and both require approval from the partnership team.

Real integrations show what working within that limit looks like. Airbyte's connector team captured raw response headers reading x-rate-limit-limit: 10 in a 2022 bug report.

PostHog's engineers added retry and backoff logic to their Workable connector to stay under the same limit (PR #65657).

A recruiting startup's production integration throttles itself to roughly one request per second across worker processes (tali-platform PR #948).

One caveat: that repository labels its token differently than Workable's current OAuth allowance would suggest, so treat the official table as the product fact and this repo as evidence of the engineering pattern.

There is a second, undocumented axis. The public widget endpoint enforces its own per-IP limit. One team burst-tested it to confirm they were rate limited rather than banned (hireoven PR #285).

At aggregator scale, one job-scraping project flagged its Workable source as broken after zero jobs came back across 7,306 boards (Job-agent issue #4).

To be fair: 60 sustained requests per minute is plenty for small nightly syncs. The friction shows up in bursts, backfills, and multi-worker fan-out.

How teams handle Workable 429 responses

What follows is implementation guidance drawn from the repositories above, not documented Workable behavior. The pattern the teams converged on has three parts.

• Watch the headers: track X-Rate-Limit-Remaining and pause until X-Rate-Limit-Reset when it hits zero
• Back off on 429: bounded exponential backoff on any 429 response, capped so a stuck job fails loudly
• Budget per worker: divide the request budget across processes; a shared limit with parallel workers is how teams blow past 10 per 10 seconds without noticing

How do Workable API tokens and scopes work?

Workable's token model is genuinely granular. You pick read and write resource scopes at token creation, set expiry anywhere from 30 days to 2 years, and apps can use OAuth 2.0. The details live in the token help article.

For security-conscious teams that want least-privilege integrations, this is a genuine strength.

The operational gotchas hide in the class system. There are three token classes: account tokens are self-serve, but OAuth and partner tokens both require partnership approval.

The Nango team hit exactly this wall when scoping their integration (issue #821), and workable.com/developers confirms the two-track split.

Granular permissions have a dark side: failures can be silent and per-job. One production team watched a valid admin token disqualify candidates on every job except one. The cause was collaboration rules that covered only certain departments.

They logged 1,110 silent 403 failures out of 5,173 attempts before finding the root cause (tali-platform PR #535).

Two more things to plan around. Browser calls are not supported: Workable's troubleshooting article says server-to-server only, and the 2022 Stack Overflow question about CORS sits unanswered.

And the base URL is per-tenant ({subdomain}.workable.com/spi/v3), a recurring gotcha for multi-tenant connectors.

How does pagination work in the Workable API?

This is a strong part of the design. SPI v3 uses since_id and max_id cursors for pagination, supports created_after and updated_after filters, and returns an absolute paging.next URL (v3 changelog). Cursors keep long scans consistent when the dataset changes mid-scan.

The friction lives in the details, and each item below traces to a production repo:

• Absolute next URLs: Workable returns full URLs where many client frameworks expect relative paths; Airbyte's generic cursor handling 404'd on stripped base paths (issue #18136)
• Creation-ordered cursors: an updated_after filter exists, but the cursor itself follows record IDs, which complicates incremental sync keyed on update time (PostHog PR #65657)
• No pagination on the widget: the public jobs widget endpoint returns everything in one response (get-a-job PR #392)

For large, clean backfills, cursors beat page numbers. Keep that in mind for the comparison below: 100Hires uses page numbers, and that tradeoff cuts both ways.

What can you build with the public Workable API?

The documented public SPI v3 spec exposes 66 paths and 80 operations, by our count of the machine-readable spec embedded in the reference pages.

Around 29% of those paths cover HR suite functions: employees, time off, and departments. The API supports fewer recruiting write operations than the path count suggests.

The headline fact: in the documented public spec, jobs are read-only. There is no POST, PUT, PATCH, or DELETE on /jobs anywhere in it, and job creation is absent from the help center's capability list.

The one writable job-adjacent object is Requisitions, gated to Hiring Plan accounts.

Workable also has partner programs for sourcing, assessments, video interviews, background checks, and HRIS. Those require a partnership application, and their API specs are not public, so developers cannot assess in advance what access they provide.

In practice, building on the public spec means: no programmatic job creation from your own tools, and no automated multi-board publishing.

Candidate creation is job-scoped or talent-pool-scoped (no bare POST /candidates), and there are no batch endpoints anywhere in the documented spec.

One point needs clarification: custom fields are accessible. The spec we extracted exposes job questions and custom attributes through documented endpoints.

A subtler issue is that Workable has three separate public interfaces, and only SPI v3 carries a public API reference. The documented SPI v3 is one. The jobs widget endpoint (no pagination, its own unpublished rate limit) is the second.

The jobs.workable.com marketplace endpoint is the third, and some employers publish only there, so widget-based adapters silently return zero jobs (freehire PR #717).

Change management adds friction of its own. The legacy public endpoint was migrated to a new POST-based v3 shape via a 302 redirect that one team discovered in production (auto-job-tracker PR #65).

Another team encountered silent schema drift: a description field became empty, forcing per-record detail fetches that then tripped the rate limit (hireoven PR #285). No changelog entry for either change was identified in the sources we reviewed.

Webhooks in the public Workable API

The /subscriptions endpoint lets you create, list, and delete webhooks. There is no update operation: changing a filter requires deleting and recreating the webhook. The reviewed webhook docs contain no signing-secret or rotation language.

That is fine for simple notification workflows. If you need to confirm a payload really came from Workable, the reviewed docs describe no built-in mechanism for doing so.

How good is the Workable API documentation?

The complaint you'd expect to find barely exists in searchable form. What exists instead is a set of measurable frictions you can verify in one click.

The authoritative reference at workable.readme.io is a client-rendered app. A plain fetch of the reference page returns a shell of about 30 words.

Any tool that reads the raw HTML gets that shell instead of the endpoint catalog. It does provide an llms.txt for AI agents, a modern touch worth noting.

The rest of the developer documentation is spread across the readme.io reference and five or more help center articles, with no single page that combines endpoints, auth, and limits. Guide URLs do not follow an obvious pattern; /docs/pagination returns a 404.

The troubleshooting article's own feedback widget shows that 3 of 7 readers found it helpful (a tiny sample, worth exactly that much), compared with 19 of 26 for the overview article.

The undocumented widget per-IP limit had to be reverse-engineered from response headers and burst tests by the teams cited earlier. Documented SPI limits, to be clear, are published plainly.

The developer ecosystem shows a similar pattern across the channels we searched (Reddit, Stack Overflow, GitHub, Hacker News, social).

A $100 bounty for a Workable integration has been open more than two years, with several contributor attempts and none merged (Revert issue #551).

Contributors on that bounty could not obtain live test credentials, and PostHog's connector author implemented the integration using only documented parameters.

Only two Stack Overflow questions about this API surfaced in our searches, and both (including the CORS one) were still unanswered when we checked. The community Node wrapper we found last shipped an update in 2017.

None of this is a scandal. It becomes a real cost when your integration breaks at 2am and the answer isn't in the docs.

How does the 100Hires API compare?

The 100Hires API serves the same purpose: recruiting automation for candidates, applications, jobs, and webhooks. The two APIs make different tradeoffs. Here is the row-by-row view; every cell is sourced in the sections above or in the 100Hires OpenAPI spec.

Now the four places where 100Hires loses this comparison.

First, auth granularity. A 100Hires key is all-or-nothing for what its user can see: no OAuth2, no scoped keys. Workable's scope model is objectively more granular for least-privilege setups. The flip side is one key class with no approval gate and no scope matrix to configure.

Second, pagination. Page numbers are simpler and give you total_count up front, but they can skip or duplicate records when the dataset changes between fetches. Workable's cursors are the technically stronger pattern for large syncs.

Third, the default rate limit. The out-of-the-box limit of 100 requests per 10 minutes is lower than Workable's standard rate limit.

The difference is that support can raise the 100Hires default for new keys on request, per the 100Hires API documentation; Workable's reviewed public docs describe no way to raise its limit.

Fourth, new keys stay disabled (401) until company verification passes, which creates a limitation for brand-new accounts.

Two more notes for completeness. 100Hires v2 webhooks carry per-webhook HMAC secrets with zero-downtime rotation; legacy v1 webhooks use a different, older payload format, so register through v2.

And 100Hires provides an MCP server, so AI assistants like Claude or Cursor can interact with the same API through natural-language prompts.

Workable integrations beyond the API

Three common routes for custom integrations lead into Workable: the native REST API, the official Zapier app, and unified-API middleware such as Merge, Apideck, Knit, or Bindbee.

The only genuine integration complaints we found on Reddit live at the Zapier layer, not the raw API.

In a Zoho CRM thread, a hiring team found that custom fields such as assessment scores were not exposed for mapping; a commenter suggested bypassing Zapier and using the direct API.

A separate thread shows a cryptic Zap error with zero replies.

A market of paid middleware exists to abstract ATS APIs. That is evidence that ATS integration in general carries real cost, not evidence of Workable-specific pain.

Treat vendor numbers as vendor claims: Merge advertises 14 syncable Workable objects, Apideck's own FAQ counts roughly two data models for the same API, and the estimate that a native build takes one to two months comes from Bindbee itself.

100Hires offers the same two options: the native API above plus a 100Hires Zapier integration with 3 triggers and 3 actions, and native automations that do not consume Zapier quota.

Which ATS API should you build on?

Choose Workable's API if you already use Workable, mainly need read-heavy analytics or BI syncs, want scoped least-privilege tokens, or plan to build a commercial partner app and go through the partnership program.

Choose the 100Hires API if you need job creation and multi-board publishing through a publicly documented spec (both are absent from Workable's documented public SPI v3), batch pipeline operations, self-service access without a partner application, or MCP and AI-agent workflows.

One caveat applies here too: new 100Hires keys stay disabled until company verification.

One data point from our own sales calls, shared anonymously: a prospect who was weighing Workable against 100Hires asked whether they could systematically export their data through an API before signing. It is a good test to run against any ATS, ours included.

One last observation. An integration builder described on LinkedIn how AI coding tools reduced connector work from weeks to an afternoon.

If that experience generalizes, the hard part of ATS integration stops being the code and starts being what the API exposes in the first place.

Start a free 100Hires trial and generate an API key in Settings, or read the spec first at api.100hires.com/v2/openapi.json.

Frequently asked questions

Does Workable have an API?

Yes. Workable offers a REST API (internally SPI v3), documented at workable.readme.io and included with all Workable plans. The public spec is read-heavy: strong retrieval coverage, thinner write coverage. 100Hires publishes its own full API spec at https://api.100hires.com/v2/openapi.json for side-by-side reading.

What is the Workable API rate limit?

Account tokens allow 10 requests per 10 seconds; OAuth and partner tokens allow 50. Requests past either limit return HTTP 429 with X-Rate-Limit headers. The reviewed public docs describe no process for raising these numbers. The 100Hires API default is 100 requests per 10 minutes per key, raisable through support.

Can you create or edit jobs with the Workable API?

Not in the documented public SPI v3 spec, where jobs are read-only. Requisitions (Hiring Plan accounts) are the writable job-adjacent object, and deeper partner tracks are approval-gated. The 100Hires API includes job creation, updates, publishing, and batch job board publishing.

Is the Workable API free?

API access is included in all Workable plans per its help center, with no separate API fee; current plan pricing is listed at https://www.workable.com/pricing. 100Hires includes API access on all plans at no extra cost as well, with no per-request fees.

Does Workable have webhooks?

Yes. The public spec exposes /subscriptions with create and delete, no update-in-place, and the reviewed docs contain no signing-secret language. 100Hires v2 webhooks include per-webhook HMAC signing secrets with zero-downtime rotation.

Can you call the Workable API from a browser?

No. Workable's troubleshooting article states the API is server-to-server only, with no CORS support for browser calls. 100Hires publishes its full API contract at https://api.100hires.com/v2/openapi.json so you can check the details before building.

What is the best Workable API alternative for developers?

It depends on the write coverage you need. If you need job writes without partner approval, the 100Hires API offers self-service access to full CRUD through a public spec. For the product-level view beyond the API, see the guide to Workable alternatives.