ATS integration
ATS integration is the work of connecting an applicant tracking system to other software - a job board, a sourcing tool, an HRIS, an analytics product - so recruiting data moves between them automatically instead of by manual export.
Also called: applicant tracking system integration, ATS integrations.
Key points
- ATS integration is the project of wiring an applicant tracking system to other software; the ATS API is just the interface it uses.
- Integrations run outbound - jobs to boards, hires to an HRIS - and inbound - candidates from sourcing tools into the pipeline.
- Common patterns: job distribution, candidate sourcing, HRIS handoff, analytics extracts, and background-check round-trips.
- Cost scales with the number of ATSs supported - build connectors in-house for a few, use a unified API for broad coverage.
What ATS integration means
An applicant tracking system rarely operates alone. It needs job postings pushed out to job boards, candidates pulled in from sourcing tools, hired employees handed off to an HRIS, and pipeline data fed into analytics. ATS integration is the connective work that makes those handoffs automatic. Where an ATS API is the technical interface - the endpoints and the auth - ATS integration is the project of actually using that interface to wire two systems together and keep them in sync.
Integrations run in both directions. Outbound, data leaves the ATS: open requisitions syndicate to job boards, hires flow into onboarding and payroll. Inbound, data enters the ATS: candidates from a sourcing tool or a careers-page form land as new applications. Most real integrations do both, and 'ATS integration' as a phrase usually points at a specific paired use case rather than one generic connection.
The common types of ATS integration
A handful of patterns cover most ATS integration work. Job distribution pushes requisitions from the ATS out to job boards and aggregators. Candidate sourcing pulls profiles from LinkedIn, browser extensions, or referral tools into the pipeline. The HRIS handoff moves a hired candidate's record into an HR system so onboarding can begin. Reporting and analytics extracts pipeline and funnel data into a BI tool or warehouse. Background checks and assessments send candidate data to a vendor and write the result back.
Each pattern touches a different slice of the ATS data model and carries a different difficulty. A read-only analytics extract is light. A bidirectional candidate sync that writes back into a customer-configured pipeline is heavy, because it has to respect that customer's custom stages and required fields. Naming the specific pattern before scoping the work is what keeps an ATS integration project honest.
Why ATS integration is hard, and build versus buy
The difficulty of ATS integration is rarely the first connection - it is the second, third, and thirtieth. Every ATS has its own API, schema, auth flow, and rate limits, so a connector built for Greenhouse does not transfer to Lever or Workday. On top of that, each customer configures their ATS differently, so even a single ATS needs per-customer handling. A product that integrates with whatever ATS its customers happen to run is signing up to build and maintain a connector per system, indefinitely.
That is the build-versus-buy decision. Building connectors in-house makes sense when the integration is your product's differentiation, or when you only need one or two ATSs. Routing through a unified API makes sense when you need broad coverage and the integration is plumbing rather than the product - the unified API maintains the connectors, so a provider's API change is its incident, not yours. For the public job-postings slice specifically, the integration is reading published jobs across many companies, which is closer to a jobs-data API than to a per-customer ATS connection.
FAQ
What is the difference between an ATS integration and an ATS API?+
An ATS API is the technical interface an applicant tracking system exposes - its endpoints, authentication, and data model. An ATS integration is the project of using that API to connect the ATS to another system and keep data in sync. The API is what you build against; the integration is what you build. One ATS API can support many different integrations.
Should I build ATS integrations in-house or use a unified API?+
Build in-house when ATS integration is your product's core differentiation, or when you only need to support one or two systems. Use a unified API when you need broad coverage across many ATSs and the integration is plumbing under a product whose value is elsewhere - it maintains the connectors so provider API changes are absorbed for you. The deciding question is whether the integration is the product or a means to it.
Is reading public job postings an ATS integration?+
Not in the usual sense. Reading the jobs a company publishes on its careers page is public, read-only, and most useful across many companies at once - that is a jobs-data problem, closer to a job board API. A true ATS integration connects to one company's private recruiting system behind per-customer authorization. If the goal is job postings across many employers, you want jobs data, not a per-customer ATS integration.
JobsPipe is the jobs-data API behind this glossary - 30+ sources, one schema, 5,000 requests/month free.
Get a free API keyRelated