Two ways to get AI into recruitment: a layer on top of your ATS, or an ATS with the intelligence inside it. What each costs, plus which layer connects to which ATS.
Integration details for the conversation layers verified via official vendor pages, May 2026. Vendors revise their connectors regularly. Where a connection is not listed on public pages, it’s phrased as such, not as “cannot”.
Most buyer’s guides for recruitment AI start with the tool. Which is best, which has the most features, which wins the comparison. Then they narrow to the question that feels practical: which one connects to the system I already run?
That question is worth asking, and it’s worth knowing that it already contains an assumption. It assumes the ATS is fixed and the AI is the variable. For plenty of agencies that’s exactly right, and the second half of this guide is a factual matrix for them: five vendors, which ATSes they name, at what depth, with sources and dates.
But the assumption is no longer free. Until recently, AI in recruitment genuinely was something you added, because no system of record had it built in. That changed. There are now two shapes on the market, and picking between them is a bigger decision than picking between two notetakers. If you’re choosing an ATS this year rather than defending the one you have, the connector matrix is the wrong place to start.
This guide covers both. Where the intelligence should sit, what each model actually costs, and then the connector detail for the layer you’d buy if you’re keeping your ATS.
Start with what the work is. Recording an intake, understanding it, turning it into structured fields, parsing a CV into a candidate profile, matching that candidate against an open vacancy, generating a client-ready document. Every one of those operations reads from and writes to the same set of records.
Model one: a layer on top. The AI product does the understanding and the ATS holds the records. Between them sits a connector. This is the model that built the category, and it has a real advantage: you keep everything you already have. Your history, your workflow, your back office, your contracting, your invoicing. You add a capability without a migration, and if it doesn’t work out you turn it off.
The cost is the connector, and it’s more than an implementation line item. Every field the AI extracts has to be mapped to a field somebody else defined. Every dropdown value has to match an option list you don’t control. Every schema change on either side is a maintenance event. And the connector is a permission boundary too: what one system knows about who may see what does not automatically survive the trip. That tax is not one-off, and it’s paid on the parts of the product you use most.
Model two: the intelligence inside the system of record. Here the records and the AI are the same product. A parsed CV lands in your own fields because they are your fields. An extracted notice period is proposed against the record it came from. Matching reads the live vacancy because there is only one copy of it. There is no mapping layer, no format translation and no connector to maintain, because nothing crosses a boundary.
The cost of this one is equally real, and it’s the one vendors in this category are least keen to write down: it’s a migration. You move your data, you retrain your team, and you give up whatever your old system did that the new one doesn’t. That’s a bigger decision than adding a tool, and it should be treated as one.
Simply is the second model. It used to be the first, and this article used to say so. It is now the ATS and the CRM: a data model you define yourself, with recording, parsing, matching, document generation and reporting inside it. Which means Simply is not on the list of tools that connect to your ATS. It’s on the list of systems you’d compare your ATS against, and that’s a different conversation with a different set of risks.
If you’re buying a layer, the single most useful thing you can do is find out what “integration” means in each vendor’s sentence. They use the same word for very different things, and the difference decides how much manual work is left after purchase.
The base level. The tool produces output, a summary, a parsed CV, a set of data points, and you copy it into your ATS by hand. Sometimes via a clean export button, sometimes via copy-paste out of a transcript. It works, and for a solo recruiter or a small team it’s sometimes enough. But the time the AI saved partly leaks back out in the retyping, and at volume that adds up fast.
The tool writes data points straight into the right fields. Desired salary to the salary field, availability to the availability field, a parsed CV onto the candidate card. No more retyping. The win isn’t only time, it’s data quality: fewer typos, consistent input, no fields skipped because it’s Friday afternoon.
The hard part here is field recognition. An ATS has dropdowns, enums, date fields and required formats. A tool that can only write plain text doesn’t help you. Ask specifically how the vendor handles a picklist whose options you changed last month, and what happens to a value that doesn’t match any of them.
The deepest version of a layer. The connection reads as well as writes. It pulls open vacancies out of the ATS so a candidate can be matched against them, it knows which client belongs to which assignment, and updates run both ways.
Level 3 is also where the model starts arguing against itself. By the time a tool is reading your vacancies, writing your fields, holding your conversation history and matching your database, the interesting question is no longer how good the connector is. It’s why there are two systems.
Tip for the vendor conversation. Don’t ask “do you have an integration with my ATS?” The answer is almost always yes. Ask which of the three levels it’s at, whether it writes to specific fields or only free text, whether it reads vacancy data back, and whether the connector is native or runs through middleware like Zapier. Native versus middleware is often the difference between a week of implementation and a quarter.
The playing field first. These are the systems you meet most in the Dutch recruitment landscape. The descriptions are neutral and factual, based on the Recruitment Tech benchmark 2026. One thing has changed since the last version of this article: for Simply these are now the systems it’s compared against, not systems it plugs into. Read the table as competitors described fairly, which is the only way a comparison is worth anything.
| ATS | Type | Strong at |
|---|---|---|
| Bullhorn | US ATS/CRM | Larger and international agencies |
| Mysolution | NL staffing/payroll platform (acquired OTYS) | Staffing and payroll, end-to-end |
| OTYS | NL agency ATS | Strong multiposting |
| Carerix | NL ATS/CRM | Relationship-driven work, top-rated in NL |
| Byner | NL, Salesforce-based | Staffing and secondment |
| Tigris | NL, Salesforce-native | Agencies on the Salesforce platform |
| Salesforce | Global CRM-as-ATS | Enterprise and consultancy |
| Recruitee | NL origin (now Tellent) | Corporate and in-house |
| Greenhouse | US enterprise ATS | Tech and scale-ups |
| AFAS | NL ERP/HR | Recruitment as a secondary module |
Two things stand out. The Dutch landscape is a mix of strong regional players and international systems, which is why a layer that connects brilliantly to Greenhouse and Ashby is useless to an agency on Carerix. And several of these are genuinely better than an AI-native newcomer at things that have nothing to do with AI: multiposting and career sites, mid-office and contracting, payroll. Those are the columns to check before anyone gets excited about a summary.
The matrix below sets four conversation layers against the ATSes they support. A check means the connection is listed on public pages; a dash means it isn’t, which is emphatically a “not documented at the time of writing” rather than a “cannot”.
Simply is not a column here, and its absence is the point. It’s an ATS, so it doesn’t connect to one. If you want to see it against the systems in the left-hand column, that’s the comparison hub, not this table.
| ATS | Carv | In2Dialog | Metaview | Fireflies |
|---|---|---|---|---|
| Salesforce | — | ✓ | — | — |
| Bullhorn | ✓ (embedded) | ✓ | ✓ | via middleware |
| Mysolution | — | — | — | — |
| Byner | — | — | — | — |
| Tigris | ✓ (API) | — | — | — |
| Carerix | ✓ (embedded) | ✓ | — | — |
| OTYS | ✓ (embedded) | ✓ | — | — |
| Recruitee | ✓ (API) | — | ✓ | — |
| AFAS | — | — | — | — |
| Greenhouse | ✓ (API) | — | ✓ | ✓ (native) |
| Lever | ✓ (API) | — | ✓ | ✓ (native) |
| Ashby | — | — | ✓ | ✓ (native) |
The matrix tells a story the individual marketing pages don’t: the layers cluster around different parts of the market, and the NL-native ATSes are thinly covered by everyone. Below, per vendor, what the connection concretely involves.
Simply is a Dutch AI-native ATS and CRM, which puts it in the left-hand column of the matrix rather than along the top. Candidates, jobs, clients, applications and placements live in a data model you configure yourself rather than one you wait for a release to change. Because that model is metadata, everything downstream picks up your changes: parsing writes into the fields you defined, search and permissions cover them, and the API serves them.
The AI is not a connected product. Online meetings are captured natively through Google and Microsoft, phone and in-person conversations through the desktop and mobile apps, and what comes out lands on the candidate as proposed field changes a human approves, each with a confidence score and the line it came from. Matching scores a candidate against a live vacancy with the arithmetic published, so a client challenging a shortlist gets an answer rather than a shrug. Every claim in a summary is anchored back to the moment in the audio it came from.
What that means for this article’s question: there is no integration level, because there is no hop. And there is no write-back to another ATS either, in either direction. Simply does not sync with Bullhorn, Carerix or anything else in that category. Moving to it is a one-way migration, four weeks, with a data audit in week one so the things your export won’t carry come out before you commit rather than in week five.
For the rest of your stack there are six OAuth connectors, named and complete: Gmail, Outlook, Google Calendar, Zoom, Slack and HubSpot. Anything beyond those goes through the public REST API, generated from the same model the interface uses, with workspace keys and HMAC-signed webhooks. Source: simplyrecruit.ai/en/features/integrations (2026-05-29).
Carv stands out with an embedded view: for Bullhorn, Carerix, OTYS, and Jobylon, Carv runs as a view inside the ATS, so the recruiter doesn’t have to switch. For Lever, Greenhouse, Workable, Recruitee, Tigris, Avature, JobAdder, Loxo, and RecruitNow the connection runs via API. Carv has an official partnership with Carerix and supports VOIP via Aircall. On price, Carv sits around €60 per user per month (per Capterra). Strong at the Bullhorn/Carerix/OTYS combination, and broad across the international ATSes. Source: carv.com/integrations (2026-05-29).
In2Dialog is a Dutch tool with direct integrations for Salesforce, Bullhorn, Carerix, Ubeeo, and OTYS (the logos on the homepage). It fills your ATS during the interview with recognised data points. Telephony runs through a paid add-on. Mysolution, Byner, and Tigris are not mentioned on the public pages. Good coverage on the relationship-driven NL ATSes (Carerix, OTYS) and the international classics. Source: in2dialog.com (2026-05-29).
Metaview lists 62+ recruiting tools on its integrations page, including Bullhorn, Recruitee, Personio, Greenhouse, Lever, Ashby, SmartRecruiters, Gem, Workday, and iCIMS. The method behind that number is not publicly specified. The NL-native ATSes (Mysolution, Byner, Tigris, OTYS, Carerix) are not named. That makes Metaview strong at international ATS stacks, with less coverage on the specifically Dutch systems, a factual observation, not a judgement. Source: metaview.ai/integrations (2026-05-29).
Fireflies is a general meeting notetaker with native ATS connectors for Ashby, Greenhouse, Lever, and BambooHR. Other systems run via viaSocket or Zapier; Bullhorn and Workable via middleware. There are no native connectors with NL-native ATSes, and no Dutch AI summaries (only raw transcription). That makes Fireflies mainly interesting for international, English-language stacks on the large US ATSes. Source: fireflies.ai/integrations/applicant-tracking-system (2026-05-29).
Three situations, and they lead to genuinely different answers.
Your ATS is fine and you’re not moving. Plenty of agencies are here, and it’s a defensible position: the back office works, the contracting works, the history is intact, and a migration would burn a quarter. Then buy a layer, and buy it on connector depth. Use the matrix, cut everything that doesn’t name your system, and put the level-1-2-3 question to whoever is left before the demo rather than during it. Budget for the connector as an ongoing cost, not a one-off.
You’re up for renewal, or the ATS is the actual complaint. This is where the second model earns its hearing. If the reason you’re looking at AI is that your system of record is slow, rigid, or shaped like somebody else’s agency, adding intelligence on top solves the smaller half of the problem and adds a connector to maintain. Compare the AI-native systems against your incumbent directly, on the comparison hub, and read the migration terms before the feature list. What you give up matters more than what you gain, because the gains are easy to demo and the losses show up in month three.
You run on an international ATS (Greenhouse, Lever, Ashby). The layer market opens right up. Metaview and Fireflies are strong here with native connectors on exactly these systems, and Carv connects over API. The choice shifts from “who connects at all” to “who delivers the best intelligence and the support you need in your language”, if that matters to you.
If you want to weigh this against your broader tool choice, not just the connection but the whole fit with your agency economics, the guide to choosing recruitment AI per agency type is the logical next read.
If you’re staying on your ATS, a deep connection is worth paying for. Four things it genuinely gets you, and the caveat attached to each.
Less duplicate work. A recruiter who retypes data points after every conversation is doing work a level-2 connection removes. At hundreds of conversations a month that’s not a marginal gain. The caveat: it removes the typing, not the checking. Somebody still verifies what was written.
Better data quality. Manual entry means typos, forgotten fields and inconsistent formats. Field recognition plus validation beats a human on a Friday afternoon. The caveat: only for the fields the connector supports. Your custom fields, your enums and the ones you added last quarter are exactly where connectors are thinnest.
Matching against what’s actually open. A level-3 connection reads live vacancies rather than an exported snapshot, so the AI matches against the requirements as they stand now. The caveat: latency and mapping errors put the two copies out of step, and the failure mode is silent.
Audit and traceability. Under the EU AI Act and GDPR you have to be able to show what a decision rested on. A connection that makes every written value traceable makes that oversight practical. The caveat, and it’s the one people underestimate: an audit trail that stops at the system boundary is half an audit trail. If the reasoning lives in one product and the record in another, “show me why” means reconciling two logs with two clocks.
That last point is the honest summary of the whole comparison. Every one of these benefits is real, and every one is capped by the fact that there are two systems. The AI-native model removes the cap and charges you a migration for it. Which of those you’d rather pay is a genuine decision, and anyone telling you it’s obvious is selling one of the two.
A level-headed sequence, whichever way you end up going.
Step 1. Name the problem before naming the tool. Is the complaint that conversations don’t turn into records, or that the records themselves are the problem? The first is a layer. The second is a system change, and no connector fixes it.
Step 2. If you’re keeping the ATS, cut on the matrix. Which vendors name your system at all? Everything else is a conversation you don’t need to have. That often narrows the list considerably, especially on a NL-native ATS.
Step 3. Ask the integration-level question in writing. Level 1, 2 or 3? Native or via middleware? Which fields, including custom ones? Does it read vacancies back? Send it before the demo, so the answer is written down rather than improvised.
Step 4. If you’re weighing a system change, read the losses first. Every AI-native vendor has a list of things it doesn’t do. Multiposting, career sites, mid-office depth, certifications you may need. Ask for that list in writing, and treat a vendor who doesn’t have one as a vendor who hasn’t thought about it.
Step 5. Pilot on one team, and measure. Whichever model you pick, run it on one desk before you commit the agency. Measure whether the data actually lands clean and whether the time saved is real. Not “feels good”, but counted.
The 2026 question isn’t which AI tool connects to your ATS. It’s whether the intelligence belongs on top of your system of record or inside it, because that decides what you’re buying and what it will cost you two years out.
Both answers are defensible. If your ATS is doing its job, buy a layer and buy it on connector depth, using the matrix above and the level question. If your ATS is the thing you’re actually complaining about, adding intelligence on top is treating a symptom, and it’s worth comparing the AI-native systems properly instead.
Simply is in that second group. It’s the ATS and the CRM, with recording, parsing, matching, formatting and reporting inside one model you shape yourself, six connectors for the rest of your stack and a public API for everything else. If you want to see how it stacks up against the system you run today, the comparison hub covers twelve of them, including what you’d be giving up, and the migration page sets out what four weeks actually looks like.
About the author
Remo Vloet is a co-founder of Simply, the AI Operating System for recruitment agencies: inbox, meetings, sourcing, CV parsing, search and matching, documents and automation in one system. With a background in building complex software, he contributes to the technical vision behind Simply.
LinkedInArticles by Remo VloetThat depends on which of the two models you buy. A conversation layer like Carv, In2Dialog, Metaview or Fireflies does not replace anything: your ATS stays the system of record and the layer feeds it over a connector. An AI-native ATS is a replacement, because the intelligence and the records are the same system. Simply is the second kind. It is the ATS and the CRM, so there is nothing to sit on top of, and moving to it is a migration rather than an integration.
If you are keeping your ATS, the realistic shortlist is narrower than for international systems. Carv runs embedded in Bullhorn, Carerix and OTYS and connects to Tigris and Recruitee over API. In2Dialog names Salesforce, Bullhorn, Carerix, Ubeeo and OTYS. Metaview and Fireflies largely do not name the NL-native systems on their public pages. Simply is not on that shortlist and should not be: it is an ATS itself, so it is something you would move to rather than connect.
A native integration is built directly between the two products, usually faster, more stable and with deeper field support. A Zapier or middleware connection runs through a middle layer that shuffles data back and forth, needs more maintenance and is often more limited in which fields it touches. For production use at volume, native is almost always preferable. Ask each vendor explicitly whether the connection with your ATS is native or goes through a middle layer, and who fixes it when it breaks.
No, and that is worth stating plainly rather than discovering later. Simply does not sync with Bullhorn, Carerix or anything else in that category, in either direction. Simply is the system of record itself, and two systems that both claim to be the truth drift apart. What does exist is six OAuth connectors for the rest of your stack, Gmail, Outlook, Google Calendar, Zoom, Slack and HubSpot, plus a public REST API with HMAC-signed webhooks for everything else.
For a layer on top of your ATS, that differs per vendor and per connector: sometimes the connection sits in the licence, sometimes there is a one-off build fee, and the lead time matters as much as the price. Ask for a realistic implementation timeline with references from clients on your ATS. For a move to an AI-native system the question changes shape entirely: with Simply, support from the migration team is currently completely free of charge, and what it actually costs you is your own people's time, roughly half a day a week over four weeks plus one week of running both systems.
For a bolt-on layer it depends on the level. At level 1 you export output and paste it yourself. At level 2 the tool writes data points into specific fields. At level 3 the connection also reads, pulling open vacancies back for matching. Ask each vendor which level applies to your ATS, because the word integration covers all three. Simply sits outside that scale: it does not write back to another ATS at all, because the data already lives in Simply and there is no second system to keep in step.
Recruitment software comes in six types, from the ATS to the AI-native system that replaces the stack. Here is how they work, what they cost, and how to choose in 2026.
Remo Vloet9 min.
What separates a modern ATS from a legacy system? A vendor-neutral checklist: core layer, 2026 features, compliance (GDPR + EU AI Act) and integrations.
Remo Vloet13 min.
GDPR and EU AI Act-proof recruitment AI: what the law demands, how to verify a vendor claim, how Carv, Metaview and Simply score, plus 10 vendor questions.
Remo Vloet11 min.
Find out how Simply can completely evolve your workflow.No slides, just product.