ATS API Integration: Real-Time Recruiting Data, Candidate Pipelines, and Hiring Automation

ATS API integration connects your product to applicant tracking systems such as Greenhouse, Lever, Workable, iCIMS and SmartRecruiters, so it can read candidates, jobs and applications and write updates back. Unified.to's ATS API does this across 162 ATS integrations through one data model, reading and writing each source ATS at request time with no customer records at rest. This guide is for teams building recruiting, assessment, sourcing and background-check products: it covers use cases, the problems to plan for, and when to build in-house or use a unified API.

For the objects and integrations the API covers, see the ATS API overview; for the ATS vendors' own APIs, see 15 ATS APIs to Integrate With in 2026; to compare unified API platforms for ATS, see Best Unified API for ATS Integrations in 2026.

What systems does an ATS API integration connect to?

Applicant tracking systems such as Greenhouse, Lever, Workable, iCIMS and SmartRecruiters act as the system of record for recruiting. They manage jobs, candidates, applications, interviews, documents, scorecards, and recruiting activity throughout the hiring process.

But ATS platforms don't operate in isolation. Recruiting analytics tools, assessment platforms, interview software, background check providers, job boards, and AI screening products all need access to ATS data. ATS API integration gives those products read and write access to recruiting platforms without manual exports, delayed syncs or duplicated logic.

What is ATS API integration?

ATS API integration is the process of connecting software products to applicant-tracking platforms via APIs in order to programmatically access recruiting data.

In practice, this includes:

• Retrieving candidates, jobs, and applications
• Tracking application stage changes
• Scheduling and updating interviews
• Attaching documents, and writing scorecards where the ATS allows it
• Writing assessment results or status updates back to the ATS
• Acting on created, updated and deleted events on supported integrations

Where does an ATS API end and an HR & Directory API begin?

An ATS API ends at the hiring decision and an HR & Directory API begins at employment, and Unified.to keeps that boundary explicit.

• ATS APIs handle the recruiting lifecycle: candidates, applications, interviews, offers, and hiring decisions.
• HR & Directory APIs handle employment: employees, org structure, locations, benefits, payroll artifacts, and identity.

An ATS may signal that a candidate was hired (for example via a hired_at timestamp), but that does not create an employee record automatically. The application decides when and how to create or update an employee using the HR & Directory API.

This explicit handoff is intentional. It prevents incorrect assumptions, supports complex hiring scenarios (contractors, rehires, multiple offers), and keeps ATS and HR responsibilities cleanly separated.

How do request-time reads differ from batch ATS data syncs?

A request-time ATS API reads and writes the source ATS on every call, while a batch sync copies recruiting data into a separate database every few hours and serves reads from that copy.

What does a request-time ATS API do?

A request-time ATS API:

• Reads the source ATS at request time, and writes to it on supported integrations
• Does not rely on cached replicas
• Returns the source ATS's current state on every call

Unified.to's ATS API uses a pass-through architecture. Every API request reaches the underlying ATS live, reads don't wait on a sync job, and no customer records sit at rest in Unified.to.

Why do batch syncs break recruiting products?

Batch-based ATS integrations lead to:

• Delayed candidate status updates
• Missed interview changes
• Out-of-date job postings
• Inconsistent analytics

For recruiting products, where a stage change should trigger the next step, scheduled syncs add hours of delay.

What data does an ATS API return?

An ATS API returns candidates, applications, jobs, interviews, activities, documents, scorecards, companies and application statuses; on Unified.to these are nine objects, and the fields each integration reads and writes, and which webhooks it supports, are listed on its page in the ATS integration list. These behaviours shape how you build:

• Status has two values. Applications carry a normalized status and the ATS's own stage name in original_status. The Application Status object, each ATS's list of stages, is read-only; an application's own status can be updated on supported integrations such as Greenhouse, Lever and Workable.
• hired_at is a signal, not an action. It doesn't create an employee; your application decides when to create one through the HR & Directory API.
• Documents go in as base64 and come out as expiring links. You upload with document_data (base64) and download from document_url, which expires after one hour.
• Activities keep the ATS's own label. An activity's type is NOTE, TASK or EMAIL, and sub_type carries the ATS's own label as free text (for example a call, a client interview or a reference check), readable on integrations such as Bullhorn, JobAdder, SmartRecruiters, Teamtailor and Vincere, and writable on Bullhorn and JobAdder (as of 19 October 2026).
• Some fields are opt-in. Fields that need an extra vendor call per record are slow fields, excluded by default and returned when you ask for them with fields. On Greenhouse, for example, application offers and job public_job_urls are slow fields.

Provider-specific fields stay reachable through raw. Unified.to doesn't invent missing fields or infer recruiting semantics.

What do teams build with ATS API integrations?

Teams build recruiting analytics, sourcing, interview and assessment, background-check, job distribution and AI screening products on ATS API integrations.

Recruiting Analytics & Reporting

Build dashboards that track pipeline velocity, time-to-hire, candidate sources, and recruiting performance across multiple ATS platforms. See How to Deduplicate and Visualize Talent Pools Across ATS Platforms.

Candidate Sourcing Tools

Create sourcing products that create candidates and applications in your customers' ATS on supported integrations, then follow each application's stage. See How to Source Candidates Externally.

Interview Scheduling & Assessment Platforms

Coordinate interviews, write results back as activities or documents, and write scorecards where the ATS allows it (Greenhouse and Lever scorecards are read-only).

Background Checks & Verification

Initiate background checks when applications reach specific stages and store results or documents back in the ATS. See How Assessment and Background Check Vendors Integrate with ATS Platforms.

Recruitment Marketing & Job Distribution

Read open jobs for career sites, and create, update and remove postings on job boards such as Indeed, LinkedIn Talent Hub and Monster (all in beta, 19 October 2026). See How to Build a Job Board.

AI-Based Candidate Analysis

Analyze resumes and applications using AI while keeping ATS data as the source of truth. For agents, see How to Build an AI Recruiter Agent with Unified MCP.

Which ATS systems does Unified.to's ATS API support?

It supports 162 ATS integrations on every plan, from enterprise and agency systems to job boards: Greenhouse, Lever, Workable, Ashby, SmartRecruiters, iCIMS, Jobvite, Teamtailor, Bullhorn, JobAdder, Zoho Recruit, SAP SuccessFactors, Workday and Workday (Legacy), plus Oracle HCM, Indeed, LinkedIn Talent Hub and Monster in beta (as of 19 October 2026). Writes depend on the integration: Greenhouse, Lever, Bullhorn and Zoho Recruit create, update and remove candidates and create applications; Workable and Ashby create and update both; Workday (REST) creates candidates and scorecards but has no application object; Workable and SmartRecruiters jobs are read-only. Each integration's page lists its objects, fields and webhooks.

Candidate updated events are native on Greenhouse, Lever, Ashby, SmartRecruiters, Teamtailor and Workable, with native deletes on all but Workable, and candidate events come from virtual webhooks on iCIMS, Bullhorn, Jobvite, Zoho Recruit and SAP SuccessFactors. Workday (REST) sends no ATS events, so read it on a schedule. Greenhouse's native candidate webhooks are created by hand in Greenhouse; see Configure Greenhouse Native Candidate Webhooks.

Customers such as Sync2Hire (19 ATS integrations in two weeks with two engineers), Floats and RecView build on it.

How do ATS change events reach your application?

ATS change events reach your application through native webhooks, which Unified.to forwards when the ATS sends them, or virtual webhooks, which check the source ATS at an interval you set (as often as every minute on paid plans), detect changes and deliver events. Both work on supported integrations and objects, and both use the same subscription interface and event schema, so backfills and ongoing changes arrive the same way.

How often are changes detected, and what happens on failure?

• The virtual webhook interval is configurable
• Failed deliveries are retried three times at once; virtual webhooks then back off and retry for about two weeks, and a webhook that keeps failing is marked unhealthy
• Each webhook reports whether it's healthy, with its most recent runs

Checks that find no changes aren't billed; each page of changes delivered counts as one API call.

To keep a copy in your own database, Database Sync (Grow, Pro and Scale) writes changes into MongoDB, MySQL, Postgres, MSSQL, MariaDB, Supabase or Snowflake for objects with native or virtual webhooks, such as candidates and applications on Greenhouse or Lever. Objects with no change events on an integration, such as Workday (REST) jobs, can't be kept current that way.

How do authentication and permissions work?

Unified.to runs each ATS's authorization flow (OAuth2 or API key) and maps Unified.to scopes to that ATS's permissions:

• OAuth2 and API-key-based flows are handled automatically
• Unified.to scopes map to each ATS's own permissions
• Embedded authorization components or manual flows are supported

Connections are identified by a connection ID, not credentials.

Unified.to manages:

• Token exchange and refresh
• Each vendor's OAuth behaviour
• Signed webhook payloads (HMAC-SHA256) and a 501 response for operations an integration doesn't support
• Connection health: when each connection was last healthy or unhealthy, and the status code behind a failure

How is ATS data secured?

Unified.to secures ATS data by not keeping it: candidate and recruiting records pass through at request time, and only connection credentials and operational metadata are stored, encrypted at rest.

No customer records at rest

• No candidate or recruiting records are stored at rest
• No ATS payloads are cached or mirrored
• API call logs hold metadata only (endpoint, timing, status), never payloads

Document Handling

• Documents are uploaded via base64
• Retrieved through time-limited URLs
• Download links (document_url) expire after one hour, and Unified.to keeps no copy of the file

Controls and Compliance

• SOC 2 Type II, with the 2026 report available on request through the trust centre
• GDPR, CCPA/CPRA, PIPEDA, HIPAA
• TLS 1.2+ in transit; AES-256 at rest for operational metadata
• SAML SSO and IP restriction (Pro and Scale); admin and member roles
• Log shipping to Datadog, Grafana or ClickHouse (Pro and Scale)

How do ATS records reference HR employees?

Certain ATS objects include optional user_id or user_ids fields that reference HR employees (for example, recruiters or interviewers). These references are contextual only.

What Unified.to does not do:

• Automatically convert candidates into employees
• Trigger HR record creation when hired_at is set
• Infer employment from recruiting state

Hiring ends in the ATS. Employment begins in HR & Directory, when the application decides. See HR API Integration for the employee side.

What constraints should you plan for?

Plan for write support, object availability and stage names that vary by ATS integration:

• Write support varies by integration
• Some objects may be read-only
• Recruiting stages differ widely across platforms
• Some fields are slow fields: excluded by default because they need an extra vendor call per record, and returned when you request them with fields
• No inference or automation beyond what the ATS supports

These constraints are intentional: Unified.to provides recruiting primitives, not hiring logic.

Should you build ATS integrations in-house or use a unified API?

Build in-house when one or two ATS platforms are central to your product and you need every vendor-specific feature; use a unified API when your customers run many different ATS platforms.

Building In-House

• Multiple ATS APIs to learn and maintain
• Provider-specific authentication, pagination, and rate limits
• Custom polling, retries, and reconciliation
• Ongoing maintenance overhead

Using a Unified.to ATS API

• One API across 162 ATS integrations
• Reads from the source at request time, with no replica
• Centralized authentication, event delivery, and maintenance
• Usage-based pricing with unlimited connections, from $750 a month on Grow

What are the best practices for ATS API integrations?

These practices keep ATS integrations correct when integrations differ:

• Use original_status when you need the ATS's own stage name
• Treat hired_at as a signal, not an automation
• Expect fields and writes to differ by integration
• Monitor connection health and webhook delivery
• Keep recruiting and employment logic in the application layer

How do you start building ATS integrations with Unified.to?

Start with a 30-day free trial on Grow or Pro. If your product depends on candidate pipelines, interview updates, assessments or hiring signals, batch syncs and one-off ATS integrations leave you maintaining stale copies and per-vendor code.

Unified.to's ATS API gives you authorized access to recruiting data across 162 ATS integrations, read from the source at request time, with no customer records at rest and no vendor-specific code paths to maintain.

→ Start your 30-day free trial

Test ATS integrations with live reads, writes and webhooks.

→ Book a demo

Talk through your recruiting or ATS → HR use case with the Unified.to team.