Best Unified API for Read and Write ATS Integrations (2026)
October 30, 2025
Recruiting software lives and dies by integrations. Job records, candidate profiles, and application status changes move across dozens of Applicant Tracking Systems. Keeping that data consistent is usually slow to build and expensive to maintain because every ATS differs on authentication, object models, write constraints, and event delivery.
We built Unified's ATS API to reduce that complexity. Instead of integrating separately with each ATS, teams integrate once to a unified ATS API surface and work with a consistent set of objects and endpoints—while still accounting for provider-specific limitations.
This post explains how our ATS API works in practice, what it supports today, and where provider constraints matter.
What we mean by an ATS unified API
Our ATS API is a category-specific unified API that connects your product to multiple Applicant Tracking Systems behind a consistent schema and endpoint structure.
Instead of managing provider-specific authentication flows, pagination, object naming, and webhook formats, you integrate once and work with normalized ATS objects such as candidates, jobs, applications, interviews, documents, companies, and scorecards. Support for individual objects and write operations varies by provider, and we document those differences explicitly.
When you need provider-specific fields, we make those available alongside the unified model so you can support advanced or custom use cases without branching your entire integration.
Typical usage patterns include:
- Read: list or retrieve candidates, jobs, applications, or interviews
- Write: create or update candidates, applications, notes, or evaluations (where the provider allows it)
- Events: receive native webhook events when an ATS supports them, or virtual webhooks when it doesn't, with polling and change detection managed by us
What matters when choosing an ATS unified API
When teams evaluate ATS unified APIs, the difference isn't integration count—it's how the API behaves under real product constraints.
Read and write support, by provider
Most ATS platforms do not offer full write access across all objects. Some objects are read-only, others allow create but not update or delete. A usable unified API needs to make those limits visible so teams can design features intentionally instead of discovering gaps late.
Consistent object models
We normalize core ATS objects so teams don't maintain per-provider mappings for candidates, applications, or jobs. That reduces engineering overhead and makes testing predictable, especially as you add more ATS integrations.
Provider-specific fields when required
Recruiting data is rarely uniform. We support provider-specific fields so teams can access the data they need without abandoning the unified model.
Real-time access and event delivery
When ATS providers offer native webhooks, we pass those events through directly. When they don't, we provide virtual webhooks by polling the provider API and detecting changes. Event timing and object coverage depend on the provider, and polling-based delivery introduces measurable latency that teams should plan for.
Zero persistent data storage
Unified operates as a stateless, pass-through platform. We do not store customer ATS records at rest. Data is processed in memory and returned immediately. We retain only minimized, redacted operational logs, and customers can store credentials in their own secrets manager if required.
Developer experience
We provide SDKs, embedded authorization components, sandbox data, and observability tooling so teams can build and support ATS integrations without maintaining per-provider code paths.
MCP for controlled tool-calling
For teams building AI features, our MCP server makes specific ATS actions callable as tools. These tools map directly to API operations and must be explicitly enabled. MCP does not add autonomy—it exposes existing ATS actions in a controlled, auditable way.
Unified ATS coverage today
Our documentation currently lists 68 supported ATS integrations.
This includes platforms such as Greenhouse, Lever, Workable, SmartRecruiters, iCIMS, Bullhorn, Teamtailor, and JazzHR. The ATS API follows the same architectural principles as the rest of Unified: real-time, pass-through requests with no caching of customer data, and native or virtual webhook delivery depending on provider capabilities.
Important note on write support
While the unified ATS API defines create, list, retrieve, update, and remove endpoints for core objects, actual write support varies by provider and by object. This is a property of the underlying ATS APIs, not something a unified layer can override.
Examples from providers commonly referenced by customers:
- Greenhouse: scorecards exist but have no writable fields
- Lever: scorecards exist but have no writable fields
- Workable: jobs and some other objects are read-only
- JazzHR: candidates and jobs are read-only
- SmartRecruiters: jobs are read-only, while other objects support writes
We surface these constraints in the integration matrix so teams can decide which features to enable per provider.
ATS objects and operations
The unified ATS API organizes core objects around a consistent set of operations:
- Candidate
- Job
- Application
- Interview
- Document
- Scorecard
- Company
Each object has documented endpoints for create, list, retrieve, update, and remove, subject to provider support. One notable exception is application status, which is list-only across the unified model.
Because ATS providers enforce different rules around deletion, updates, and audit trails, teams should always rely on the provider capability matrix rather than assuming universal CRUD behavior.
Event delivery: native and virtual webhooks
We support two event delivery paths:
- Native webhooks when an ATS provider emits events
- Virtual webhooks when the provider does not, using polling and change detection
Two practical implications:
- Event latency varies by provider and polling interval when virtual webhooks are used.
- Not every ATS object emits events. Documents, interviews, jobs, or scorecards may require polling-based detection rather than event-driven updates.
Our goal is to give teams a single webhook interface while being explicit about where provider limitations affect timing and coverage.
Common use cases
Candidate intake and synchronization
Read candidates and applications across multiple ATS providers and write updates where supported, using provider-specific fields when needed.
Evaluation and feedback
Read scorecards where available and write evaluation data through the objects and fields each ATS supports. Some providers do not allow scorecard writes.
Application tracking
Subscribe to native or virtual webhook events for application changes, designing ingestion to handle polling-based delay when required.
AI features with MCP
Use MCP to expose specific ATS actions—such as listing candidates or submitting evaluations—as callable tools. All actions remain constrained by provider write support and explicit permissions.
Key takeaway
If you're building recruiting or HR software that depends on ATS integrations, the hard problems are write constraints, event coverage, and long-term maintenance—not just connectivity.
Unified's ATS API is designed for teams that need:
- Real-time, pass-through access to ATS data
- Clear documentation of provider-level write constraints
- Native and virtual webhook support without maintaining polling logic
- A stateless architecture that avoids storing customer records
Start with the objects your product truly depends on, confirm provider write support early, and build against the documented constraints. That's how ATS integrations stay reliable as you scale.