ATS Integration
Workable CV Formatting Integration: A Guide for Agencies
Workable holds your candidates and jobs, but it does not turn a messy incoming CV into a client-ready document. Here is how a CV formatting integration connects to Workable through partner integrations and the API, which route fits which job, and where the built-in formatting stops.
Written by: Saply Team
A Workable CV formatting integration is a connection that pulls a candidate’s raw CV out of Workable, reformats it into your agency’s branded template, and syncs the result back against the same candidate record. It runs through the routes Workable already exposes for external tools: the partner integrations you switch on inside the account, the public REST API, and no-code automation on top of that API. The goal is a submission-ready CV without the recruiter leaving Workable or retyping a single field.
For a staffing agency, Workable is the system of record for candidates, jobs, and pipeline stages. What it is not is a document tool. A CV arrives as a PDF or a two-column Word file, and something still has to turn it into the layout your client expects. That gap is where a formatting integration earns its place.
How Workable handles CVs on its own
Workable stores the original resume against the candidate and extracts the fields it needs to run the pipeline: name, contact details, work history, and the answers to any custom questions. That is enough to search, filter, and move a candidate through stages. It is not the same as producing a branded, consistent document to send to a client, which is a formatting and presentation job rather than a data-storage one.
So the practical picture for an agency desk looks like this: the candidate lives in Workable, but the client-facing CV gets built somewhere else and, too often, by hand. An integration closes that loop.
The three ways to connect a formatting tool to Workable
There are three supported paths for wiring an external tool into Workable, and choosing the wrong one is how agencies end up with duplicate records and a sync nobody trusts.
Partner integrations. Workable publishes a set of listed integrations you enable from inside the account: sourcing tools, assessments, background checks, video interviewing, and more. You authorize the connection and it works with the field mapping the vendor already built. This is the fastest route and needs no developer. The limit is that you can only use tools that have a published listing, and you inherit the design decisions the vendor made.
Public API. Workable exposes a REST API that external systems use to read and write candidate and job data. The developer documentation describes it as a way to “show jobs on your website, get data from your Workable account, or bring in candidates from other systems” (Workable Developer API). A formatting tool uses the read endpoints to fetch the candidate and their resume, and the write endpoints to push structured data or comments back. This route gives you full control over which records move and how they map, at the cost of engineering time.
No-code automation. For event-driven handoffs without building against the API directly, Workable connects to no-code platforms like Zapier and Make, which sit on top of the same API and a Workable API token. A new candidate in a stage can trigger an action in another system. It is excellent for notifications and lightweight triggers, and a poor fit for high-volume two-way sync where field-level accuracy matters.
Before you commission a custom build, check the partner list first. Most agencies over-engineer their first integration, paying for an API project to do something a published connector already handles. The API is the right tool when you need field-level control or a two-way sync at volume, not when you need a candidate to trigger a Slack message.
What the Workable API actually exposes
If you or a vendor build against the API, it helps to know what the candidate side looks like, because it sets the ceiling on what any formatting integration can do. The endpoints are documented publicly and organized around jobs and candidates.
| Capability | What it does | Notes from the docs |
|---|---|---|
| List a job’s candidates | Returns a collection of candidates for a job | Default page size 50, maximum 100 per page (API reference) |
| Read one candidate | Returns a single candidate profile and fields | Requires the r_candidates scope |
| Create a candidate | Adds a candidate to a specific job or the talent pool | POST to /jobs/:shortcode/candidates (API reference) |
| Update a candidate | Adds comments, tags, or moves stages | Fetching, creating, and updating profiles are all supported (Workable API docs) |
The pattern worth noticing is that the API is built for structured candidate data moving in and out. It supports “extracting detailed candidate information” and “updating existing candidate profiles” including custom-field answers (Workable API documentation). What it does not do is produce a formatted, branded document. That presentation step is exactly what a formatting layer adds on top.
The CV formatting gap on top of Workable
Workable gives you a clean candidate record. What it does not give an agency is a client-ready CV in your house template, and this is where recruiters quietly lose time. The harder work sits around the record, not inside it: reflowing a messy two-column CV, translating a Dutch or French resume, anonymizing a candidate for blind screening, and matching the same structured profile against an open role. That is a parsing and formatting workload, not a data field in the ATS.
A dedicated CV formatting layer sits on top of Workable through the API rather than replacing anything inside it. In Saply the same engine parses the incoming CV, reformats it into your agency template inside Word or Google Docs, anonymizes it if a client wants blind screening, and scores it against the vacancy. The recruiter works from Workable as usual and gets a submission-ready CV back. For the mechanics of that sync, our guide to CV parsing integration walks through how structured data moves between a parser and an ATS, and the wider ATS integration picture shows where formatting fits alongside the rest of your stack.
The honest caveat: if your CVs are already clean, single-column, and all in one language, you may not need a second tool at all, and the extra layer is overhead. The case for it is volume and variety. It compounds when you process dozens of messy, multilingual CVs a day and want the structured profile, the branded document, and a match score out of a single upload.
Choosing the right route
Each route trades control against effort. This is the decision most agencies get wrong on the first try, usually by reaching for the API when a partner integration would have done, or leaning on no-code automation where they needed reliable two-way sync.
| Route | Effort to set up | Control over mapping | Best for |
|---|---|---|---|
| Partner integration | Minutes | Low | Standard tools with a published listing |
| Public API | Developer days | Full | Custom sync, field-level accuracy |
| No-code automation | An afternoon | Medium | Event triggers and notifications |
The rule of thumb: the tools you touch every hour, like CV formatting, justify a proper native or API connection, while the once-a-day handoffs are fine on no-code automation. Spending engineering effort on a notification is effort in the wrong place.
The GDPR question you cannot skip
Any integration that reads a CV out of Workable is processing personal data, and for a European agency that is not a footnote. The GDPR requires a lawful basis for processing (Article 6) and limits processing to specified, explicit purposes with data minimization (Article 5). In practice that means asking any formatting vendor where the CV is processed, where it is stored, and how long it is kept. For agencies whose clients run a DPO, EU data residency is one of the first questions on the due-diligence list, so an EU-resident workflow keeps that answer simple (Saply security overview).
Frequently asked questions
Does Workable have a CV formatting feature built in?
Workable stores the original resume and extracts candidate fields for its pipeline, but it does not reformat a CV into your agency’s branded template for client submission. That presentation step is a formatting job, and agencies add it through a partner integration or the API rather than expecting the ATS to do it.
Does Workable have an API for candidates?
Yes. Workable exposes a public REST API for reading and writing candidate and job data, documented at workable.com/developers. The candidate endpoints let an external tool list a job’s candidates, read a single profile, and create or update candidates, which is what a formatting integration uses to fetch a CV and sync structured data back.
How do I add CV formatting on top of Workable?
Connect a dedicated CV formatting tool through the Workable API or a partner integration. The tool pulls the candidate’s raw CV, reformats it into your template, and the recruiter gets a client-ready document without leaving Workable. See our comparison of the best CV formatting software for staffing agencies for how the options differ.
Which integration route should I choose for Workable?
Match the route to the job. Partner integrations for standard tools that already have a listing, no-code automation for notifications and simple triggers, and the API only when you need field-level accuracy or two-way sync at volume. Reaching for the API on a workflow a partner integration already handles is the most common and most expensive mistake.
How does a Workable integration compare to a JobAdder or Vincere setup?
The shape is the same across ATS and recruitment CRM platforms: a partner or marketplace list, a public API, and a no-code automation route. The differences are in which tools have published connectors and how each API is structured. See our companion guides to JobAdder integrations and Vincere integrations for the same breakdown on those platforms.