Best Unified API for ATS Integrations in 2026
June 10, 2026
Unified.to supports 85 ATS integrations — the largest published ATS catalog among unified APIs — behind nine unified objects, with a public capability matrix listing readable fields, writable fields, and webhook events per integration, on a pass-through architecture that stores no candidate data at rest.
Merge (50+ ATS, sync-and-cache) is the most mature enterprise option; Kombo is the EU-strong HR specialist; Apideck, Knit, and Truto each fit narrower shapes. The right choice depends on which objects you need to write, on which specific ATS platforms — and whether the vendor publishes those answers before you sign.
Recruiting products rarely fail at reading ATS data. They fail at writing it back.
Reading candidates and jobs from Greenhouse or Lever s the easy half of the integration. The hard half is the write path: pushing a sourced candidate into your customer's ATS, moving an application to the next stage, submitting evaluation data after an interview. Every ATS enforces different write rules — some objects are read-only, some allow create but not update, some have no writable fields at all — and most unified APIs abstract over those rules instead of documenting them. Teams discover the gaps at month 3, after the feature is committed to a customer, not during evaluation.
If your primary requirement is ATS coverage breadth, the choice is made before you evaluate any vendor. Unified offers two paths for assessment use cases: the ATS API, which triggers on application status changes and writes results back as activities across 85 integrations with no marketplace partnership required, and the Assessment API, which embeds directly into the recruiter's ATS workflow but is limited to 6 integrations and requires a partnership arrangement. Most customers use the ATS API path. The rest of this post covers that path.
This post compares the unified API platforms that support ATS integrations — Merge, Kombo, Apideck, Knit, Truto, and Unified.to — on the dimensions that determine whether your write-dependent features ship: object coverage, write support, event delivery, and where the data actually flows. Every Unified.to number in this post comes from our published ATS integration matrix, which lists readable fields, writable fields, required fields, webhook events, and list parameters for every integration.
Can a unified API write to any ATS?
The most common assessment integration flow looks like this: your application listens for an updated application event, checks the unified status field — which maps all vendor-specific stage names (first interview, second interview, background check, hired, rejected, and roughly 11 values total) into one consistent field across all integrations — triggers the assessment when the right status is reached, and writes the result back to the ATS. The status field is readable and unified across all 85 integrations. It is not writable by design: ATS platforms control their own pipeline transitions. The write tables below show what you can write once that trigger fires.
Every vendor in this comparison answers yes. The answer is also nearly meaningless.
Write constraints are a property of the underlying ATS APIs, not of the unified layer on top of them. Greenhouse provides scorecard objects with no writable fields. Workable's jobs are read-only. JazzHR doesn't accept candidate or job writes at all. No unified API can override those constraints — and any platform implying uniform write support across its catalog is describing its schema, not its integrations.
The questions that actually predict whether your features ship:
- Which objects support writes, on which specific ATS integrations?
- Which objects emit change events, and how are events delivered when the ATS has no native webhooks?
- Does the platform publish those answers, or do you find out during implementation?
That last question separates the vendors more than any feature does.
Which unified APIs support ATS integrations?
Unified.to supports 85 ATS integrations behind nine unified objects, with a published capability matrix covering readable fields, writable fields, required fields, webhook events, and list parameters for every integration. The rest of this post shows what that looks like in practice.
Merge has the deepest ATS object model after Unified.to — candidates, jobs, applications, interviews, scorecards, attachments, offers, screening questions — across 50+ ATS integrations. Its docs show field-level support per integration, but there is no aggregated read/write matrix; independent reviews consistently describe write depth as strongest on candidates, applications, and attachments, and provider-dependent elsewhere. Architecture is sync-and-cache: reads hit Merge's stored copy, and freshness is bounded by sync schedule. Merge is the right answer when operational maturity and HRIS-adjacent depth outweigh real-time behavior and write transparency.
Kombo is the HR vertical specialist, with strong European ATS coverage and a model centered on jobs, candidates, applications, attachments, and users. Kombo publishes 250+ integrations across its five future-of-work categories but no ATS-specific count, and no public capability matrix — write limitations on specific integrations are clarified during sales evaluation. Architecture is sync-and-store: data is mirrored into Kombo's database, polled on a 3-hour default cadence (faster intervals are tier-gated), and a notification webhook tells your application to fetch the updated records. Kombo is the right answer for EU-heavy recruiting products that prefer reads against a cached store.
Apideck deserves credit on transparency: each integration page lists exactly which operations (list, get, create, update, delete) each object supports. The ATS model is narrow — jobs, applicants, applications, with no first-class interviews, scorecards, documents, or offers — across roughly 11 ATS integrations. Apideck shares the pass-through posture (no cached customer data), but provides no managed change detection: virtual webhook polling defaults to every 24 hours, and faster cadences are plan-dependent and unpublished. Apideck is the right answer when your ATS needs fit three objects and an embedded marketplace UX matters more than event delivery.
Knit is a genuine architectural peer — pass-through, no stored user data, webhook-first delivery across roughly 40 ATS integrations. Its push-first model streams initial and delta syncs to your webhook endpoint, which means your application owns ingestion, ordering, and idempotency. The unified ATS model centers on jobs and applications with candidates nested inside; no public capability matrix. Knit is the right answer for HR-leaning products that want pass-through architecture with a free tier to start.
Truto publishes its numbers — roughly 27 ATS integrations and 17 normalized resources — which makes it the only other vendor in this comparison treating disclosure as a feature. Its differentiator is per-tenant schema customization through JSONata transforms. The catalog is smaller and Lever support is currently flagged beta on their marketplace. Truto is the right answer when deep per-tenant schema control matters more than catalog size.
Unified's ATS API by the numbers
The unified ATS model defines nine objects — Candidate, Job, Application, Application Status, Interview, Document, Scorecard, Company, and Activity — with 135 readable properties, 118 writable properties, and 23 webhook event types across 85 ATS integrations.
Those numbers are uneven across integrations, because ATS APIs are uneven. Here is what coverage looks like on widely used systems:
| Integration | Readable fields | Writable fields | Webhook event types |
|---|---|---|---|
| Greenhouse | 97 | 40 | 10 |
| Bullhorn | 81 | 45 | 10 |
| Zoho Recruit | 78 | 46 | 12 |
| Ashby | 78 | 26 | 9 |
| Lever | 77 | 29 | 12 |
| Workable | 73 | 21 | 6 |
| SmartRecruiters | 69 | 17 | 12 |
| Teamtailor | 48 | 19 | 8 |
| iCIMS | 47 | 17 | 6 |
| JazzHR | 35 | 25 | 4 |
| And here is write support by object across the full catalog — the table that determines which features you can build: |
| Object | Integrations with write support | Integrations with read support |
|---|---|---|
| Candidate | 63 of 85 | 79 of 85 |
| Application | 47 of 85 | 71 of 85 |
| Job | 45 of 85 | 82 of 85 |
| Document | 34 of 85 | 39 of 85 |
| Activity | 35 of 85 | 39 of 85 |
| Company | 12 of 85 | 24 of 85 |
| Interview | 11 of 85 | 22 of 85 |
| Scorecard | 7 of 85 | 13 of 85 |
| Read the scorecard row carefully, because it explains this entire category. Only 7 of 85 ATS integrations support scorecard writes — not because of anything in the unified layer, but because most ATS platforms don't allow external systems to write evaluation data. Greenhouse and Lever both model scorecards with zero writable fields. More importantly: scorecards are for human evaluators. Automated assessment results write back as activities — notes associated with a candidate or application that appear directly in the ATS, visible to the recruiter without leaving their system. Assessment is Unified's most common customer use case, and every customer using it writes results back via activity, not scorecard. The document object handles the accompanying PDF: you provide the URL of the report stored on your system, Unified transfers it to the ATS, and associates it with the application or candidate ID. Practically all ATS integrations accept documents as PDFs only. |
The same logic applies to interviews (11 of 85 writable) and application status, which is list-only across the unified model because ATS platforms control status transitions through their own pipeline rules.
Event coverage follows the same pattern:
| Event | Integrations emitting it |
|---|---|
| Job created / updated | 52 of 85 |
| Candidate created / updated | 50 of 85 |
| Application created / updated | 42 of 85 |
| Company created / updated | 15 of 85 |
| Document created / updated | 14–15 of 85 |
| Interview created / updated | 9–10 of 85 |
| Scorecard created / updated | 6 of 85 |
| Integration counts change as the catalog grows; the integration matrix is the canonical, current source. The matrix also marks which writable fields are required on create per integration — so you know not just that a candidate write works on a given ATS, but which fields it must include. |
One design note for readers comparing object models: offers are modeled within the Application object rather than as a standalone object, with full compensation, status, and lifecycle date fields. An offer doesn't exist outside an application, and the model reflects that.
How do unified APIs deliver ATS data: pass-through vs. sync-and-store
On a pass-through architecture, a write executes against the source ATS at request time. The ATS confirms or rejects it immediately, and your application knows the result before the request returns. There is no intermediate database between your write and your customer's system, and no copy of their candidate data sitting in vendor infrastructure.
On sync-and-store architectures, a database sits between your application and the ATS. Reads return the cached copy, with freshness bounded by the sync schedule. Candidate records — PII by definition — persist in the vendor's infrastructure, which your customers' security teams will evaluate as part of their compliance scope.
Event delivery is where the architectures diverge most for ATS use cases, because most ATS platforms don't offer native webhooks. The fallback model matters:
| Delivery on ATS integrations without native webhooks | |
|---|---|
| Unified.to | Virtual webhooks: change detection at a configurable interval, as frequent as every minute. Events deliver to your endpoint with the changed records in the payload — no follow-up fetch. |
| Kombo | Polling into Kombo's store on a 3-hour default cadence; faster intervals tier-gated. Your application is notified, then fetches updated records. |
| Merge | Sync schedule is the freshness floor; faster sync is tier-gated. |
| Apideck | Virtual webhook polling defaults to every 24 hours; faster cadences plan-dependent, not published. |
| Knit | Push-first delivery to your webhook endpoint; your application owns ingestion and ordering. |
| The pattern poll → store → notify → fetch is a sync-based notification system, not change-detection event delivery. The difference shows up in your code: one model hands you the changed application record the moment it's detected; the other tells you something changed and leaves the retrieval to you, bounded by someone else's sync schedule. For recruiting automation — screening triggered the moment an application arrives, stage changes reflected across systems — that difference is the feature. |
When an ATS does provide native webhooks, Unified passes those events through directly, with the same payload format and the same subscription interface as virtual webhooks. Your application code doesn't branch on which delivery path an integration uses.
ATS is one boundary in the hiring lifecycle
A candidate doesn't live in one ATS — they move through systems. Sourced into the ATS, assessed mid-pipeline, background-checked before the offer, hired into the HRIS, onboarded into training. Each handoff is an integration boundary, and most platforms in this comparison stop at one or two of them.
Unified covers the lifecycle as adjacent unified API categories on the same platform: HR & Directory (247 integrations, where hired candidates become employees), Verifications (Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik — background checks as a first-class category, which no other unified API in this comparison models separately), Learning Management (onboarding and training systems), and Assessments — which runs in the other direction: it lets assessment and screening vendors embed into ATS pipelines, receiving recruiter-initiated orders from Greenhouse, Workable, Ashby, and others and writing results back into the ATS.
For a recruiting product, that means the integrations after the hire — and the vendors plugging into the same pipeline — run through the same platform, the same authorization components, and the same pass-through architecture as the ATS integrations.
Sync2Hire: 19 ATS integrations in two weeks
Sync2Hire builds post-application workflows for recruiting teams — a product that lives or dies on consistent application and candidate data across whatever ATS each customer runs. ATS is a category where normalization matters enormously: every system models candidates, jobs, and applications differently, and post-application workflows depend on one consistent shape.
Working with Unified.to, Sync2Hire shipped 19 ATS integrations in two weeks, writing one set of ingestion logic against the unified ATS objects instead of mapping each ATS individually. The capability matrix did the evaluation work the sales process usually hides: they knew which integrations supported which writes before committing features to customers.
How to evaluate any unified ATS API
Five questions, regardless of vendor:
- Is the capability matrix public? If write support per object per integration isn't published, the answer is being managed, not documented. You'll learn it during implementation.
- Which objects can you write, on the specific ATS platforms your customers use? Candidate writes are broadly supported everywhere. Scorecards, interviews, and offers are not — on any platform — because the underlying ATS APIs restrict them. Get the per-integration answer in writing.
- What happens on integrations without native webhooks? Ask for the default polling cadence, whether it's tier-gated, and whether events include the changed data or just a notification. The answers range from every minute to every 24 hours across this field.
- Where does candidate data rest? Pass-through architectures keep PII out of the integration layer entirely. Sync-and-store architectures put the vendor inside your customers' compliance scope. Neither is wrong; one of them extends your enterprise security reviews.
- What does month 3 look like? ATS APIs change, write rules shift, and new integrations get requested by customers you haven't signed yet. The maintenance question — who absorbs that drift — is the question the first demo never covers.
- If an ATS your customer needs isn't in the catalog, ask the vendor what happens next. On most platforms the answer is a feature request into someone else's roadmap. Unified ships new integrations in days based on customer demand. If you need it, we'll build it.
If a vendor's answer to the first question is no, the other four answers are whatever they need to be to close the deal.
Unified's answers are published: 85 ATS integrations, the capability matrix, virtual webhook cadence configurable to every minute, and a pass-through architecture with no customer ATS records at rest. Evaluate against the integrations your customers actually run — the matrix is built for exactly that.
→ Start your 30-day free trial
Frequently asked questions
Which unified API supports the most ATS integrations? Unified.to publishes 85 ATS integrations, the largest published ATS catalog among unified API platforms. Merge publishes 50+, Knit roughly 40, Truto roughly 27, and Apideck roughly 11. Kombo publishes 250+ integrations across its five HR categories combined but no ATS-specific count.
Do unified APIs support writing to ATS platforms like Greenhouse and Lever? Yes, within the limits of each ATS's API. On Unified.to, Greenhouse supports 40 writable fields and Lever 29 across the unified ATS objects. Some objects are read-only by the ATS's design — Greenhouse and Lever scorecards, for example, have no writable fields on any platform.
Which unified API supports scorecard writes? Scorecard writes are restricted by the ATS platforms themselves — most don't allow external systems to write evaluation data. Unified.to documents scorecard write support on 7 of its 85 ATS integrations in its published capability matrix. No unified API can offer broader scorecard write coverage than the underlying ATS APIs allow.
How do unified APIs handle ATS platforms without native webhooks? Approaches differ by architecture. Unified.to runs managed change detection at a configurable interval (as frequent as every minute) and delivers events with the changed records included. Sync-and-store platforms poll into their own database — Kombo on a 3-hour default, Merge on its sync schedule — and notify your application to fetch the updated records. Apideck's virtual webhook polling defaults to every 24 hours.
Does Unified.to store candidate data? No. Unified.to is a pass-through architecture: requests route to the source ATS at request time, and no customer ATS records are stored at rest. Only credentials and minimal operational metadata persist, with customer-managed secret options available on Scale tier and above.
Which unified APIs cover background checks and assessments alongside ATS? Unified.to models Verifications (Checkr, Certn, First Advantage, Socure, Verifiable, Yardstik) as its own unified API category alongside ATS, HR & Directory, Learning Management, and Assessments. Kombo includes assessment and background check within its HR-vertical scope. Knit offers a unified assessment API. Merge and Apideck don't offer a dedicated verification or background check category.