Workable: Creating candidates and attaching them to jobs

September 14, 2026

How do candidates and applications work in Workable?

In Unified.to's Workable integration, creating a candidate requires a job: Workable creates the candidate on that job. To add the same person to another job, create the candidate again with that job in job_ids. Workable keeps a separate candidate record, with its own id, for each job.

This guide explains the recommended flow and how to handle the ids you get back. To connect Workable first, see Getting started with Workable; for the objects and fields Workable supports, see the Workable integration page.

Create a candidate on a job

POST /ats/{connection_id}/candidate with job_ids set to the Workable job shortcode creates the candidate on that job. job_ids is required: a create without it returns an error and creates nothing.

• The response id is that job's candidate id. Store it.

Add the person to another job

POST /ats/{connection_id}/candidate again, with the same details and job_ids set to the other job's shortcode. The response id is a new candidate id for that job. Store it alongside the first one.

What does application create do on Workable?

In Workable a candidate on a job is the application, so POST /ats/{connection_id}/application doesn't attach anyone to a job (as of 21 October 2026). Send:

• candidate_id: a Workable candidate id
• job_id: the shortcode of the job that candidate is already on

It returns the application for that candidate and job, and can set its status (stage), screening answers or rejection in the same call. If the candidate isn't on that job, it returns HTTP 400 and changes nothing. It also returns HTTP 400 if the job is a draft, closed or archived.

⚠️ Application create no longer copies a candidate onto another job. To put someone on a second job, create the candidate on that job.

Example sequence

1. Create candidate with job_ids: [JOB1] → response id A (on JOB1)
2. Create candidate with the same details and job_ids: [JOB2] → response id B (on JOB2)
3. Later get/update the candidate or application on JOB2 → use B, not A

How do I find a candidate by email?

List candidates with the query parameter set to the email address:

GET /ats/{connection_id}/candidate?query=person@example.com

After you add a candidate to a second job, the same email may return two candidates (A on the first job and B on the second). They are different Workable records with different ids.

Do updates carry over between the two copies?

No. Changing profile details on the original candidate doesn't update the copy, and the reverse is also true. Treat each id as its own record.

Why not use email as the candidate id?

Email identifies a person, but after you add them to a second job Workable has two candidate records with the same email. Unified.to keeps Workable's native candidate ids so list, get, and application create stay unambiguous.

Which events tell me about new copies?

On Workable, candidate created and updated events come from native or virtual webhooks, and application events from virtual webhooks (as of 20 October 2026). Workable's candidate_created event feeds the native candidate created event, and only candidate_moved (a stage change) feeds native candidate updated. Workable has a candidate_deleted event, but Unified.to doesn't deliver deleted events for any Workable object (as of 21 October 2026), so a 404 on an old id is the signal to list again.

Requirements and tips

• Changing an application's stage, answers or rejection needs a Workable member id. Pass user_id when you can; otherwise Unified.to tries to resolve an admin or a member of the job's team.
• Store each candidate id as soon as create succeeds, together with the job it belongs to.
• If an old candidate id returns 404, list with query set to the email to recover the current ids on each job.