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 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:

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.