ATS-native vs ATS-adjacent. The integration question that decides adoption.

Procurement RFPs love the word integration. Every recruitment tool claims to have it. The category exists on every comparison grid, gets a checkmark from every vendor, and tells the buyer essentially nothing about what the day-to-day looks like once the contract is signed.

The phrase that does the work is ATS-native versus ATS-adjacent, and the difference between them is the difference between a tool your team uses and a tool your team eventually stops using.

What ATS-adjacent looks like.

An ATS-adjacent tool talks to your ATS, but it lives somewhere else. There is a vendor dashboard, a vendor login, a vendor URL. Data flows back and forth on a schedule (sometimes every few minutes, sometimes hourly, sometimes nightly). When a candidate goes through the tool, the candidate record in the ATS gets a link, a status update, or a note saying that the work happened over there.

ATS-adjacent works on paper because the data is being shared. The ATS knows the candidate did the video interview, completed the assessment, signed the offer, whatever. The technical integration is real.

It does not work in practice because every artefact the tool produces lives in the tool, not on the candidate record. Watching the video, reading the assessment, viewing the recording, all of that happens in a separate place. The ATS is the index, the vendor's dashboard is the library, and the recruiter has to walk between the two.

What ATS-native looks like.

An ATS-native tool produces artefacts that live on the candidate record itself. The video plays inside the candidate profile inside your ATS. The assessment results display alongside the CV. The signature lives in the offer object. There is no second tab to open, because the work the tool does shows up where the recruiter is already looking.

ATS-native is harder to ship. The vendor has to deeply understand the host ATS (data models, embed conventions, permission rules) and build a real surface inside it, not just an API integration. Most vendors do not bother, because ATS-adjacent is easier and the marketing copy reads the same.

The tools that do bother are the ones that survive long-term in your stack.

Why the distinction matters for adoption.

The first month of any new tool is when adoption is high. The team is excited, the rollout email is recent, the training session was last week. By month three or four, the team has fallen back into the rhythm of their existing workflow. The question of whether the tool survives that fall-back is the question of where it lives.

If the tool is ATS-adjacent, falling back to the existing workflow means falling back to not using the tool, because the existing workflow does not have a tab open to the vendor's dashboard. The recruiter forgets to switch tabs, skips the video, the candidate gets evaluated on the CV alone, the tool's artefact does not influence the decision. Multiply that across a team, and the tool's contribution to the funnel drops toward zero.

If the tool is ATS-native, falling back to the existing workflow IS using the tool, because the workflow is the candidate record and the artefact is on the candidate record. There is no separate behaviour to remember.

How to tell which one a vendor actually ships.

Three questions on a demo call.

1. 01Show me a candidate record in an actual customer's ATS, with the artefact your tool produces displayed on it. Not a screenshot, a live walk-through. If the vendor opens their own dashboard, the tool is ATS-adjacent.
2. 02Tell me what the recruiter clicks when they get a notification that a candidate has completed the step. If the answer involves logging into anything, the tool is ATS-adjacent.
3. 03Describe what happens when the candidate's record is exported from the ATS to a downstream system. If the artefact your tool produces is not in the export, the tool is ATS-adjacent.

The three questions are deliberately specific. ATS-native tools answer them quickly because the answers are concrete. ATS-adjacent tools answer them with sentences that contain the word integration and circle back to the dashboard. You will be able to tell.

The longer-term cost.

ATS-adjacent tools are not just adopted less, they are also harder to migrate away from when you decide to replace them. The data structures are vendor-shaped, the artefacts live in their dashboard, the historical record of every candidate touched by the tool requires an export process to extract. ATS-native tools, by contrast, store their artefacts in your ATS to begin with. When the contract ends, the data stays where it has always been.

Procurement teams sometimes describe this as data sovereignty. It is also called not being locked in. Either framing, it is a function of where the tool ships its output, not what the contract says about data ownership.

Flipbase is ATS-native by design. The video moment lands on the candidate record in your ATS, plays inside the candidate profile, exports with the record. There is no vendor dashboard for your team to forget about.