---
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-09-14T18:33:17.222Z
tag: 
description: "In the Workable integration, creating a candidate and creating an application are two different steps. Workable stores talent-pool candidates and job..."
url: "https://unified.to/blog/workable_creating_candidates_and_attaching_them_to_jobs"
---

# Workable: Creating candidates and attaching them to jobs
------
_September 14, 2026_

## Overview


In the Workable integration, creating a candidate and creating an application are two different steps. Workable stores **talent-pool candidates** and **job candidates** as separate records. Attaching someone from the talent pool to a job creates a **new** Workable candidate id for that job.


This guide explains the recommended flow and how to handle the ids you get back.


## Create a candidate (talent pool)


`POST /ats/{connection_id}/candidate` creates the person in Workable's **talent pool** (not on a specific job).

- Use this when you want to source someone before choosing a job.
- The response `id` is the talent-pool candidate id. Store it.

If that email already exists in the talent pool, Workable rejects a duplicate create. Unified returns the **existing** talent-pool candidate instead, so retries are safe when you send the same email again.


## Attach the candidate to a job (create an application)


`POST /ats/{connection_id}/application` with:

- `candidate_id` — the talent-pool candidate id from create (or list)
- `job_id` — the Workable job shortcode

Unified attaches them using Workable's [copy candidate](https://workable.readme.io/reference/copy-candidate) API (keeps the talent-pool record and creates a job-scoped copy).


> ⚠️ The application response uses a **new** `candidate_id`. Use that new id (and the returned application id) for later get/update on that job — not the original talent-pool id.

- Do **not** keep calling application create with the original talent-pool id if you already attached them to that job — Workable would create another job-scoped copy.

## Example sequence

1. Create candidate → response id `A` (talent pool)
2. Create application with `candidate_id: A` and `job_id: JOB123` → response `candidate_id: B`, application id for `B` + `JOB123`
3. Later get/update that application or job candidate → use `B` (and the application id returned), not `A`

## Finding candidates by email


You can list candidates with the `email` query parameter:


```plain text
GET /ats/{connection_id}/candidate?email=person@example.com
```


After a talent-pool create and a job attach, the same email may return **two** candidates (talent-pool `A` and job-scoped `B`). They are different Workable records with different ids.


## Updates do not sync across copies


Changing profile details on the talent-pool candidate does **not** update the job-scoped 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 attach Workable still has **two** candidate records with the same email. Unified keeps Workable's native candidate ids so list, get, and application create stay unambiguous.


## Requirements and tips

- Application create needs a Workable member id. Pass `user_id` when you can; otherwise Unified tries to resolve an admin or job team member.
- Prefer storing the application response's `candidate_id` and application `id` as soon as create succeeds.
- If an old candidate id returns 404, list by email to recover the current talent-pool and/or job-scoped ids.