ATS Unified APIs: What to Look For, Use Cases, and Options

September 24, 2025

Hiring workflows live across dozens of systems: ATS platforms, assessment tools, sourcing extensions, calendars, and job boards. Building one-off ATS integrations for each vendor is slow and brittle. Auth flows, webhooks, pagination, rate limits, and object shapes all differ, and your team ends up maintaining the same plumbing repeatedly.

An ATS unified API fixes that. Instead of writing one integration per provider, you connect once to a normalized API that abstracts the differences. Candidates, applications, jobs, interviews, and activities are available through a single surface, ready for analytics, product features, and AI agents.

What is an ATS unified API?

An ATS unified API is a translation layer between your app and multiple applicant tracking systems: Greenhouse, Lever, Workable, iCIMS, Ashby, Bullhorn, SmartRecruiters, and many more. With one schema and one auth flow, you read and write standard objects and still reach provider-specific fields when you need them.

• Direct integration: a bespoke build per vendor, with unique auth, pagination, rate limits, and webhooks to implement and maintain.
• Unified approach: normalizes Candidate, Application, Job, Interview, and Activity/Note, with raw field access for the edge cases.

The result is faster launches, less integration debt, and consistent access patterns across platforms. And if you're building AI features, a pass-through unified API plus MCP (Model Context Protocol) lets an agent read and act on ATS data through permissioned tools, without custom integration logic per system.

What to look for in an ATS unified API

When you evaluate providers, look at how the data actually moves, not just at a logo grid.

• Architecture: live or stored. The most consequential difference between unified APIs is whether they reach the source system on each call or serve from a synced copy. A stored model gives fast repeated reads but returns data that's only as current as the last sync, and it persists your customers' candidate data in vendor infrastructure. A pass-through model fetches from the source on each call: current data and nothing cached at rest, at the cost of a live round-trip per request. For live recruiter views, stage changes, and AI agents acting on current state, the difference is correct data versus stale data.
• Schema quality, not just object count. A clean ATS model normalizes Candidate, Application, Job, Interview, and Activity/Note and embeds the related data where it belongs: screening questions and result links on the job, interviews and offers on the application, scorecards and attachments where you'd expect them. Watch for the opposite pattern: platforms that expose every record as a separate first-class object look comprehensive on a checklist but can mean extra calls to assemble what one well-designed object should return, unless the API supports expansion.
• Normalized status, with the original preserved. Application status is where ATS systems differ most. A strong model maps each vendor's stages to a normalized disposition enum (e.g. NEW → HIRED → REJECTED/DECLINED/WITHDRAWN) and returns the raw vendor label alongside it, so you get a consistent pipeline view without losing the source-of-truth value.
• Custom fields and raw access. Read and write custom fields and custom objects through a metadata API, plus an escape hatch to reach vendor-specific endpoints the common model doesn't cover.
• Event delivery. Native webhooks when the ATS supports them; managed change detection, with polling, detection and retries handled for you, when it doesn't, so your app consumes one consistent event interface either way.
• Security and compliance. SOC 2 Type II, GDPR, CCPA/CPRA, HIPAA; the option to keep credentials in your own cloud KMS or secrets manager; IP allowlisting; externalized logs.
• Developer experience. SDKs in the major languages, embedded auth components, sandboxes, observability, and a genuine "build once per category" model.
• Pricing model. Usage-based pricing that scales with activity rather than per connection or per customer, with transparent overage rates.
• AI-readiness. A first-party MCP server, so ATS reads and actions are callable as permissioned LLM tools against current data, not a custom bridge you build and maintain.

Use cases for ATS unified APIs

1. Source candidates: enrich and stage sourced prospects; create candidates and applications in the ATS and write updates back. (Greenhouse, Lever, Workable, and more.)
2. Assess candidates: trigger assessments, write results back as scorecards or notes, and read stage changes to drive next steps.
3. Promote jobs: read and write job postings across supported ATS endpoints; keep statuses in sync where the ATS supports it.
4. Track applications: subscribe to stage-change and interview events; maintain live pipelines, SLAs, and breach notifications.
5. Agentic recruiting: use MCP to let an agent schedule interviews, add notes, or move stages against current data, permissioned and auditable, without custom integration code.

How the major unified APIs compare

Not all "unified APIs" behave the same. Some are sync-first (built for BI and reporting); others are pass-through (built for live product flows and agents). The biggest differences aren't in the logo count; they're in architecture, event delivery, and where your customers' data lives.

Why Unified.to is built for ATS

Most unified APIs started in payroll or CRM. Recruiting has more edge cases: custom stages, job-board variance, assessment add-ons, attachment handling, and noisy webhooks. Three architectural choices matter most.

Unification, not merging. A normalized model is only useful if it's well-designed. Some platforms expose every related record as its own first-class object, with screening questions, tags, interviews, offers and rejections all separate, which looks thorough but, unless the API supports expansion, can mean extra calls to reconstruct one application's context, plus the integration logic to stitch them back together. Unified.to embeds related data inside well-formed objects: screening questions and result links on the Job; interviews, offers, and rejections on the Application; scorecards and attachments where you'd reach for them. Fewer calls, less assembly, cleaner data.

Normalized status with the original preserved. Application disposition is the messiest part of any ATS integration: every system names its stages differently. Unified.to maps them to a normalized enum and returns the vendor's original label in original_status alongside it, so you get a consistent pipeline across every ATS without losing the source-of-truth value.

Live pass-through, including beyond the schema. Every call reaches the source system at request time; no candidate or application data is cached at rest. When you need fields outside the common model, request raw to get the original source payload alongside the normalized object, or use the Passthrough API to reach any unmodeled endpoint directly. Both run live through the same path, so reaching past the schema doesn't move you onto a staler one.

On top of that:

• Read and write across the full object graph: candidates, jobs, applications, documents, activities, interviews, and scorecards, bi-directionally, not read-only with a thin write surface.
• No customer data stored: every call fetches from the source. SOC 2 Type II; GDPR, CCPA/CPRA, HIPAA, PIPEDA; credentials in your own secrets manager, 11 supported, including AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager and HashiCorp Vault (Pro and above); log streaming to your own Datadog; IP allowlisting.
• AI-native with MCP: a first-party MCP server (US/EU/AU) makes permissioned ATS tools callable by LLMs (Claude, GPT, Gemini) so an agent can update stages, leave notes, and schedule interviews against current data.
• Developer experience: 7 backend SDKs (TypeScript, Python, Go, Ruby, PHP, Java, C#), embedded auth and SSO components for React, Vue, Angular, and JS, and observability.
• Usage-based pricing: start with a 30-day free trial; cost scales with activity, not per connection or per customer.

Integrating with ATS systems shouldn't block your roadmap or your AI strategy. With Unified.to you integrate once and get ATS coverage that's current, secure, and agent-ready.

For a head-to-head with the HR specialists, see Kombo vs. Unified.to and Finch vs. Unified.to. For the pricing-model question, see Usage-Based vs. Per-Connection Pricing for Integrations.

If your roadmap includes sourcing, assessments, analytics, or agentic recruiting features, start your free 30-day trial or book a demo.

Written by Mallory Greene.

About the author: Mallory Greene is Head of Marketing at Unified.to. She writes about integration infrastructure, unified APIs, and MCP for technical teams. Based in Toronto.