Most guides on choosing an applicant tracking system talk about features. This one is about the layer that actually determines whether the platform survives contact with your stack: integrations.
If you're the technical person pulled into an ATS evaluation, this is the part your non-technical colleagues will underestimate — and the part that generates the most post-contract pain. Here's how to map it properly.
1. Inventory every data flow, not every tool
Don't list “tools.” List directional data flows. For each system, write down what data moves, which direction, and how often:
●HRIS — candidate → employee record handoff on hire (bidirectional ideally)
●Payroll — new-hire data push (one-way, event-triggered)
●Background screening — order + status callback (bidirectional, webhook-driven)
●Calendar (Google/Microsoft) — interview scheduling + availability sync
●Video interview tools — scheduling links out, recordings/scores back
●Job boards / distribution — posting syndication out, application ingestion back
The “direction + trigger” framing exposes gaps that a flat tool list hides.
2. Classify each integration by mechanism
Not all “integrations” are equal. Push the vendor to tell you which of these each connection actually uses:
●Native pre-built integration — maintained by the vendor, lowest overhead
●Public REST API — you (or middleware) build and maintain it
●iPaaS / middleware (Workato, Merge.dev, etc.) — flexible, adds cost + a dependency
●Flat-file / SFTP batch — a red flag in 2025 for anything real-time
●“On the roadmap” — treat as does not exist
A “yes, we integrate with X” that turns out to be a nightly CSV export is a very different thing from a webhook-driven bidirectional sync.
3. Interrogate the API itself
If any integration will run through the public API, evaluate it like you'd evaluate any dependency:
●Is it REST/GraphQL, documented, and versioned?
●Rate limits — do they survive a high-volume hiring event?
●Webhooks for state changes, or are you stuck polling?
●Auth model (OAuth 2.0 vs. long-lived API keys)?
●Sandbox environment for testing before go-live?
●Data model for candidates — how are duplicates and merges handled?
4. Make compatibility a contractual gate
The most expensive integration gaps are the ones discovered after signing. Build a formal integration checklist and require vendor sign-off on compatibility before finalizing terms. A vendor's response to your integration map tells you as much about their support quality as their docs do.
The business context
This technical mapping isn't a side quest — it's stage two of a five-stage selection framework (requirements → integrations → scored shortlist → structured pilot → ROI). The full non-technical playbook, including the weighted vendor scoring matrix and implementation guidance, is here:
👉 How to Choose the Right ATS for Your Hiring Team
If you've survived an ATS migration, what integration surprised you post-contract? Drop it in the comments — the failure modes are weirdly consistent across teams.
Top comments (0)