Everything an AI agent can do with the Workable API.

A reference guide for building AI agents: every method, how to authenticate, and the permissions each one needs.

Endpoints22
API versionv3
Last updated23 June 2026
Orientation

How the Workable API works.

The Workable API is how an app or AI agent works with a Workable account: listing open jobs, reading and creating candidates, moving a candidate to the next pipeline stage, or posting a comment or rating on an application. Access is granted through an access token that carries a set of scopes, like reading candidates or writing them, and a call can only reach what the token's scopes and the account behind it permit. A subscription lets Workable push an event to a registered endpoint when a candidate is created or moved, so an integration is told about activity rather than polling for it.

22Endpoints
6Capability groups
13Read
9Write
3Permissions
Authentication
Workable authenticates every call with a Bearer access token sent in the Authorization header. A token is created in the account's Integrations settings and shown only once. Three token kinds exist: an account token tied to one account, an OAuth 2.0 token, and a partner token for building across many accounts. Calls go to the account's own subdomain under the SPI v3 path.
Permissions
Each token is granted a set of scopes chosen when it is created, like r_jobs and r_candidates for reading or w_candidates for writing. A method names the scope it needs, and a token without that scope cannot call it. Scopes are the only permission layer the API exposes; there is no per-method or per-record permission beyond what the token's account role already allows.
Versioning
The recruiting API is versioned by a single path segment, currently v3, reached under each account's subdomain. The earlier v1 and v2 APIs are deprecated but still function. v3 changed several response shapes from v2, renaming the key field to id, returning timestamps in UTC ISO 8601, and returning empty values as null.
Data model
Workable is organized around jobs and the candidates applying to them. A job has a shortcode and a set of pipeline stages; a candidate has a stable id and moves between stages, gathering comments, ratings, activities, and a disqualification state. The hiring team is modeled as members, and external agencies as recruiters. A list endpoint pages with a limit parameter and a next link.
Connect & authenticate

Connection & authentication methods.

How an app or AI agent connects to Workable determines what it can reach. There is a route for making calls, a route for receiving events, and a hosted server that exposes Workable tools to agents, and each is governed by the token behind it and the scopes that token carries.

Ways to connect

SPI v3 REST API

The REST API returns JSON and is reached under each account's own subdomain at https://.workable.com/spi/v3. A call authenticates with a Bearer access token, and a list endpoint pages with a limit parameter and a next link. CORS is not supported, so calls are made server-side.

Best forConnecting an app or AI agent to Workable.
Governed byThe access token and the scopes it carries.
Docs ↗

MCP server

A first-party hosted Model Context Protocol server at https://mcp.workable.com/mcp exposes Workable tools to AI assistants across the hiring and HR platform, covering jobs and candidates, offers, requisitions, employees, time off, time tracking, and performance reviews. It authenticates with OAuth 2.0 and supports dynamic client registration and discovery. An agent first calls get_accounts to list accessible accounts, then uses the returned subdomain for later calls. Transport is stateless streamable HTTP in JSON mode.

Best forConnecting an AI agent to Workable through MCP.
Governed byThe OAuth grant and the scopes it carries.
Docs ↗

Webhook subscriptions

A subscription registers a target URL for one event type by POSTing to /subscriptions. Workable then pushes a notification to that URL when the event fires, and the subscription can be filtered to a single job or stage. Supported recruiting events include candidate_created and candidate_moved. A target URL must be unique, and re-registering one returns a 409 conflict.

Best forReceiving Workable events at an app or AI agent.
Governed byThe r_candidates scope on the token that creates the subscription.
Docs ↗
Authentication

Account access token

An access token tied to a single Workable account, created in the account's Integrations settings with a chosen set of scopes and shown only once. It is the simplest way to call the API for one account, and it carries the lowest rate limit, 10 requests per 10 seconds. Revoking it invalidates every integration using it.

TokenBearer access token
Best forServer-side calls against a single Workable account.
Docs ↗

OAuth 2.0 token

An OAuth 2.0 access token obtained on a user's behalf, used by the first-party MCP server and by apps connecting an account through an authorization flow. It allows 50 requests per 10 seconds, a higher ceiling than an account token, and is sent as a Bearer token like any other.

TokenOAuth 2.0 Bearer token
Best forApps and AI agents connecting on a user's behalf.
Docs ↗

Partner token

A partner token is for integrations that operate across many customer accounts, such as a third-party tool building on top of Workable. It allows 50 requests per 10 seconds, and the account it acts on is selected per call by the subdomain in the request URL.

TokenBearer partner token
Best forMulti-account integrations and partners.
Docs ↗
Endpoint reference

Every Workable API method.

Filter by method, access, or permission, or search any path. Select a row for version detail, rate limits, the related webhook event, and the source.

MethodEndpointWhat it doesAccessPermissionVersion

Jobs

Methods for listing and reading jobs and their pipeline stages.4

Read-only. Accessible with all token types.

Acts onjob
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only. Accessible with all token types.

Acts onjob
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the stages of one job. Accessible with all token types.

Acts onstage
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the account-wide stage list. Accessible with all token types.

Acts onstage
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Candidates

Methods for reading, creating, and updating candidates.5

Read-only; returns a reduced payload per candidate. Accessible with all token types.

Acts oncandidate
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the fuller fields not returned by the list. Accessible with all token types.

Acts oncandidate
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A core write; uploaded by default, set sourced to false for an applied candidate. Accessible with all token types.

Acts oncandidate
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventcandidate_created
Rate limitStandard limits apply

A core write; only the supplied fields change. Accessible with all token types.

Acts oncandidate
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

A write; adds a candidate to the talent pool.

Acts oncandidate
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventcandidate_created
Rate limitStandard limits apply

Candidate actions

Methods that move a candidate through the pipeline or act on an application.4

Advances or sends back a candidate in the pipeline. Accessible with all token types.

Acts oncandidate
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventcandidate_moved
Rate limitStandard limits apply

Requires member_id; can be reverted with the revert method. Accessible with all token types.

Acts oncandidate
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Requires a member_id and a comment body. The w_comments scope also grants this.

Acts oncomment
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Records a score or evaluation on the application. Accessible with all token types.

Acts onrating
Permission (capability)w_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

People & team

Methods for reading the hiring team and external recruiters.2

Read-only. Accessible with account tokens and user tokens.

Acts onmember
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the external recruiting agencies on the account.

Acts onrecruiter
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Activity & events

Methods for reading activity streams and scheduled events.4

Read-only; includes timing, members, and RSVP status.

Acts onevent
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only.

Acts onevent
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the actions recorded against a job.

Acts onactivity
Permission (capability)r_jobs
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the timeline of a single candidate.

Acts onactivity
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Subscriptions (webhooks)

Methods for registering and removing event subscriptions.3

Needs r_candidates (or r_employees for HR events); a duplicate target URL returns 409. Accessible with all token types.

Acts onsubscription
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Read-only; the registered webhook subscriptions.

Acts onsubscription
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply

Removes where the event was being pushed.

Acts onsubscription
Permission (capability)r_candidates
VersionAvailable since the API’s base version
Webhook eventNone
Rate limitStandard limits apply
No endpoints match those filters.
Webhooks

Webhook events.

Workable can notify an app when something happens in an account, like a candidate being created or moved to another stage. A subscription registers a target URL for one event type, so an integration learns about activity without polling.

EventWhat it signalsTriggered by
candidate_createdA new candidate was created in the account, whether uploaded through the API or applied through a form. A subscription can be narrowed to a single job or stage./spi/v3/jobs/:shortcode/candidates
/spi/v3/talent_pool/candidates
candidate_movedA candidate was moved to another pipeline stage. A subscription can be filtered to a target stage, like 'hired', to be told only about moves into that stage./spi/v3/candidates/:id/move
No events match that search.
Rate limits & pagination

Rate limits, pagination & request size.

Workable limits how fast an app can call, measured as a number of requests within a rolling ten-second window, and the ceiling depends on the kind of token making the call.

Request rate

Workable meters requests by a rolling ten-second window, and the ceiling depends on the token. An account token allows 10 requests per 10 seconds, while an OAuth 2.0 token and a partner token each allow 50 requests per 10 seconds. Every response carries X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset headers so an integration can pace itself. Going over the limit returns HTTP 429.

Pagination

A list endpoint pages with a limit parameter, which defaults to 50 results and cannot exceed 100 per page. The response carries a paging object whose next field holds the URL of the following page, and an integration follows that link until it is absent. Results are not offset-based; the next link is the supported way to walk a collection.

Request size

A page returns at most 100 records, the maximum value of limit. The newest fields for a candidate are returned only by the single-candidate endpoint; the candidates list returns a reduced payload to keep pages small.

Errors

Status codes & error handling.

The status codes an agent should handle, and what to do about each.

StatusCodeMeaningWhat to do
401unauthorizedNo valid access token was provided, or the token has been revoked.Send a valid Bearer access token in the Authorization header, and generate a new token if the old one was revoked.
403forbiddenThe token is valid but lacks the scope the method needs, or the account role does not permit the action.Recreate the token with the required scope, like r_candidates or w_candidates, and confirm the account role allows it.
404not_foundThe requested job, candidate, or other record does not exist or is not visible to this token's account.Verify the shortcode or id and confirm the record belongs to the account the token is tied to.
409conflictA conflicting request, such as registering a subscription with a target URL that is already in use.Use a unique target URL per subscription, or unsubscribe the existing one before re-registering.
429too_many_requestsThe token exceeded its allowed number of requests within the rolling ten-second window.Read the X-Rate-Limit-Remaining and X-Rate-Limit-Reset headers, then back off and retry after the window resets.
Versioning & freshness

Version history.

Workable versions its recruiting API by a single path segment, currently v3, and ships dated changes through its developer documentation rather than minting a new version for each one.

Version history

What changed, and when

Latest versionv3
v3Current version
SPI v3 (current)

The current version of Workable's recruiting API, reached under each account's subdomain at the /spi/v3 path. It changed several response shapes from v2 and is the version to build against; v1 and v2 are deprecated but continue to function.

What changed
  • The key field is renamed to id across responses.
  • Timestamps are returned in UTC ISO 8601 format, like 2015-06-08T00:00:00Z.
  • Empty values are returned as null instead of empty strings.
  • Candidates are 'uploaded' by default; an applied candidate is created with sourced set to false.
  • The jobs and candidates list responses were trimmed, moving fuller detail to the single-record endpoints.
Earlier
v1 and v2 (deprecated)

The first two versions of the recruiting API. Both are deprecated but continue to function for existing integrations; new work should target v3.

What changed
  • v1 and v2 are deprecated but still respond correctly.
  • Field names and response shapes differ from v3, including the key field that v3 renamed to id.

Build against v3; the older v1 and v2 APIs are deprecated but still function.

Workable v3 changes ↗
Questions

Workable API, answered.

How does an app authenticate with the Workable API?+
Every request carries an access token in the Authorization header as 'Bearer '. A token is generated in the account's Integrations settings, where the relevant scopes are selected, and it is displayed only once at creation. Requests go to the account's own subdomain, in the form https://.workable.com/spi/v3/.
What are the scopes, and how do permissions work?+
Workable controls access through scopes chosen when a token is created, such as r_jobs and r_candidates to read, or w_candidates to write. Each method states the scope it needs, and a token missing that scope cannot call it. Scopes are the only granular layer the API exposes; beyond them, a call is bounded by the role of the account the token belongs to.
What is the difference between account, OAuth, and partner tokens?+
An account token is tied to a single Workable account and is the simplest option, but it has the lowest rate limit, 10 requests per 10 seconds. An OAuth 2.0 token and a partner token each allow 50 requests per 10 seconds; a partner token is intended for integrations that act across many customer accounts. Most endpoints are accessible with all three kinds.
How does an integration receive events instead of polling?+
An integration registers a subscription by POSTing to /subscriptions with a target URL and an event name, such as candidate_created or candidate_moved. Workable then pushes a notification to that URL when the event happens, and the subscription can be narrowed to a single job or stage. A target URL must be unique, and re-registering one returns a 409 conflict.
How do candidate assessments work through the API?+
Workable's v3 API does not expose a first-party endpoint for an agent to create or read assessments directly. Assessments are handled through Workable's assessment-provider integration, where a third-party provider exposes its own endpoints that Workable calls to invite a candidate and receive results. An agent reads the outcome through the candidate's activities and timeline rather than a dedicated assessments method.
What changed between v2 and v3?+
v3 renamed the key field to id across responses, switched timestamps to UTC ISO 8601, and now returns empty values as null rather than empty strings. Candidates are treated as 'uploaded' by default, so an applied candidate must be created with sourced set to false. The jobs and candidates list responses were trimmed, with the fuller detail moved to the single-record endpoints. v1 and v2 are deprecated but still work.
Related

More hr API guides for agents

What is Bollard AI?

Control what every AI agent can do in Workable.

Bollard AI sits between a team's AI agents and Workable. Grant each agent exactly the access it needs, read or write, area by area, and every call is checked and logged.

  • Set read, write, or full access per agent, never a shared Workable token.
  • Denied by default, so an agent reaches only what has been explicitly allowed.
  • Every call recorded in plain English: who, what, where, and the decision.
Workable
Recruiting Agent
View candidates ResourceOffReadFull use
Move candidate stage ActionOffReadFull use
Disqualify candidate ActionOffReadFull use
Per-agent access, set in Bollard AI, not in Workable