--- title: "Workable: Creating candidates and attaching them to jobs" img: https://s3.us-east-2.amazonaws.com/unified-article-images/workable_creating_candidates_and_attaching_them_to_jobs-icon.png date: 2026-09-14T17:57:00.000Z updated: "2026-10-21T14:17:14.572Z" tag: Guides integrations: workable description: "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,..." url: "https://docs.unified.to/guides/workable_creating_candidates_and_attaching_them_to_jobs" --- # Workable: Creating candidates and attaching them to jobs ------ _September 14, 2026_ ## How do candidates and applications work in Workable? In [Unified.to](https://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](https://docs.unified.to/guides/getting_started_with_workable); for the objects and fields Workable supports, see the [Workable integration page](https://docs.unified.to/integrations/workable). ## 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: ```plain text 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](https://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](https://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](https://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.