Introduction
Your job postings do not reach two of the four boards you pay for. Applications from one channel arrive without the screening answers attached. Somebody suggests an integration platform, and the evaluation stalls within a week — every product you look at is documented for developers, priced per API call, and assumes there is an engineer on your side who will own the connections. There is not. There is you, a recruiting operations lead, and a quarterly hiring target.
This is not a tooling gap. It is a category gap. The two categories that own this space, integration platforms and unified APIs, were both designed for software companies building products, not for recruiting teams running a hiring process. This essay defines what each of them actually is, in their own vendors' words, shows where recruiting falls between them, and sets out what Managed Recruiting Connectivity means as a third answer — including what it does not claim to be.
TL;DR
- A unified API normalises many vendor APIs into one interface. In Kombo's own framing, reading employees from SAP SuccessFactors is meant to look identical to reading them from Personio (Kombo docs, Aug 2026).
- That normalisation is aimed squarely at engineers: unified APIs are "designed for development teams to quickly and easily build out integrations" (Merge, Aug 2026).
- An embedded integration platform moves the work rather than removing it — your product still calls the external APIs while the platform handles auth, retries, and rate limiting (Nango, Aug 2026).
- Neither category has an operator. With an embedded iPaaS the end customer configures workflows; with a unified API the engineering team writes against the normalised interface (Apideck, Aug 2026).
- The recruiting stack resists normalisation anyway: Personio uses a per-account recruiting token, Indeed a GraphQL API with per-client rate tiers, and LinkedIn restricts access to approved partners with per-module certification.
- Managed Recruiting Connectivity names the missing option: the connections are operated for you, the buyer is recruiting operations rather than engineering, and the ATS stays system of record.
What problem do the existing categories not name?
The problem is ownership, not capability. Both incumbent categories can technically move a job posting to StepStone. Neither of them will notice at 09:00 on a Tuesday that it stopped arriving.
Look at how the categories describe their own buyer. An embedded integration platform is bought by a software company and surfaced to that company's customers: the platform "provides a complete integration layer that runs inside your product", where "your customers connect their tools, map data, and configure workflows without leaving your application" (Apideck, Aug 2026). Every noun in that sentence assumes you are shipping software. A recruiting team is not shipping software. It has no product for an integration layer to run inside.
The same holds for the operating model. Nango describes the division of labour plainly:
"Your product calls the external APIs. The iPaaS platform handles auth, retries, rate limiting, and execution."
Nango, August 2026
Read that as a recruiting lead and the problem is obvious. The hard parts named there — authentication, retries, rate limiting — are real, and it is genuinely useful that a platform absorbs them. But the first sentence still assigns the calling code to you. Somebody on your side writes it, owns it, and gets paged when a field mapping changes.
The gap shows up most clearly in what neither category sells: attention. A job that stopped reaching StepStone does not raise an exception, because nothing failed. The posting was accepted, the response was a 200, and the role simply is not visible where a candidate would look for it. Detecting that requires somebody to compare what should be live against what is actually live, on a schedule, for every channel. Both categories give you the means to run that comparison. Neither promises to run it for you, and that promise is the entire difference for a team of four recruiters carrying 35 open roles.
What does a unified API actually optimise for?
Sameness across vendors, for the benefit of whoever is writing code against it. That is a real engineering achievement, and it is also the reason the category does not reach recruiting operations.
Kombo states the goal directly:
"reading employees from an enterprise HR solution like SAP SuccessFactors will look the same as reading employees from a more SMB-focused tool like Personio."
Kombo, August 2026
That is precisely what a product team wants. If you sell payroll software to 400 companies running 40 different HR systems, one normalised employee model is the difference between a viable roadmap and an impossible one. Merge frames the audience the same way: unified APIs are "designed for development teams to quickly and easily build out integrations", and fit best where several integrations of a similar type are needed (Merge, Aug 2026).
Now apply that to a single recruiting team. You do not have 40 customers each on a different ATS. You have one ATS. Normalising across the 120-plus applicant tracking systems one unified API lists (Kombo, Aug 2026) solves a problem you do not have, and the price of that normalisation is a lowest-common-denominator data model — which is exactly where recruiting specifics live. Branching screening questions, source attribution per channel, and per-board category taxonomies are the things that break, and they are the first things a normalised model flattens.
| Embedded iPaaS | Unified API | Managed Recruiting Connectivity | |
|---|---|---|---|
| Who buys it | A software company | A software company's engineering team | A recruiting operations team |
| What it standardises | Workflow execution and auth | The data model across many vendors | Nothing — it fits each channel as that channel works |
| Who writes the calling code | Your engineers | Your engineers | Nobody on your side |
| Who notices a break | Your on-call | Your on-call | The operator of the layer |
| What it assumes you have | A product to embed it in | Several similar integrations to build | An ATS and open roles |
Why do native integrations not close the gap?
Because each one is built by a different vendor, to a different depth, on a different schedule, and none of them is accountable for the whole path from open role to candidate in your ATS.
The heterogeneity is not a matter of opinion. Read four vendors' own documentation side by side and the pattern is unmistakable. Personio splits authentication across its own products: the recruiting API token is predefined per account, while the personnel endpoints use a client_id and client_secret pair from a custom integration (Personio Developer Hub, Aug 2026). Indeed exposes a GraphQL Job Sync API, assigns each client a rate-limit tier, and does not expire postings unless something calls the expire operation (Indeed Partner Docs, Aug 2026). LinkedIn restricts its APIs to developers it has approved, requires a signed agreement, and splits the work into five modules with certification test cases (LinkedIn Talent Solutions, Apr 2026). StepStone's publicly documented apply integration, written for Workday, runs to 16 configuration steps (StepStone API knowledge base, Aug 2026).
| Channel | Protocol and auth | Who decides access |
|---|---|---|
| Personio | Per-account recruiting token; separate client_id / client_secret for personnel data | Documented and self-serve |
| Indeed | GraphQL, per-client rate-limit tier, explicit expire call required | Indeed assigns the tier |
| Two-legged OAuth, Middleware Platform, five modules, certification | LinkedIn approves the partner | |
| StepStone | ATS-side configuration project, 16 documented steps for Workday | Agreed per integration project |
Four channels, four access models, three of them gated by someone other than you. No native connector spans that, because no vendor has an incentive to build the other three vendors' halves.
The bookkeeping compounds as well. A partner integrating LinkedIn has to create and persist a Client ID, Client Secret, Organization URN, and Contract URN for every customer it onboards, and keep those values current as contracts change. Indeed adds a second axis: an expired posting can be reactivated within 30 days, and its sourcedPostingId may change after that window, so any report keyed on that identifier diverges without anyone noticing. None of this is difficult in isolation. All of it is permanent, and it accrues to whoever owns the connection.
What does Managed Recruiting Connectivity mean?
It means the connections between your ATS and your hiring channels are operated as a service, with the operating burden on the provider rather than on you, and with your ATS unchanged underneath.
Four properties define it, and each one is a deliberate refusal of something the other categories do:
- Operated, not shipped. The deliverable is a working connection under observation, not an SDK, a sandbox, or a set of credentials. If a board changes a field, the fix is the provider's work item.
- Bought by recruiting operations. The buyer is the person who owns time-to-post and candidate quality. Evaluation should not require an engineer to read API documentation.
- Channel-shaped, not normalised. Where a board supports branching screening questions or a specific source parameter, the connection uses it, rather than flattening it into a common schema.
- Non-custodial. The layer holds no system of record. It moves jobs outward and candidates back, and the authoritative record of both stays in the ATS.
Operated is the load-bearing word. In practice it means somebody other than you closes the loop when a recruiter marks a role as filled in the applicant tracking system: the posting is expired on each board, the change is confirmed rather than assumed, and a failure to confirm becomes a ticket in the provider's queue instead of an unread alert in yours. That is an operational commitment about who is watching on a Tuesday morning, and no software library can contain it.
The fourth property is the one worth dwelling on, because it is where trust is won or lost.
with your stack?
What does it deliberately not change?
The ATS stays the system of record. That is a constraint the category accepts, not a limitation it apologises for.
This matters for three concrete reasons. First, reversibility: if a connectivity layer holds no authoritative data, removing it is an afternoon rather than a migration. Nothing has to be exported back out, because nothing authoritative ever left. Second, accountability under GDPR: Article 17 obliges the controller to erase personal data without undue delay on any of six grounds (EU GDPR, Art. 17, Aug 2026), and that obligation is far easier to discharge when there is one authoritative copy and every other copy is derived and disposable. Third, regulatory scope: the EU AI Act places risk assessment, bias testing, human oversight, and transparency duties on the deployer, and those duties do not transfer to a vendor (EU Artificial Intelligence Act, Aug 2026).
A category that quietly became the system of record would inherit all three problems and hand you none of the benefits. Managed Recruiting Connectivity is defined partly by declining that role.
How do you tell which of the three you need?
By asking who is going to own the connection in eighteen months, not by comparing feature lists today.
| Signal | You need an embedded iPaaS | You need a unified API | You need Managed Recruiting Connectivity |
|---|---|---|---|
| What you sell | Software with an integrations page | Software serving customers on many different HR systems | Nothing — you are hiring |
| Who evaluates it | A product manager | A backend engineer | A recruiting operations lead |
| Integration count | Long-tail, customer-specific | Dozens of the same shape | Four to ten channels around one ATS |
| Depth needed | Configurable multi-step workflows | A consistent read model | Channel-specific behaviour that survives contact with a board |
| Failure handling | Your on-call rota | Your on-call rota | Someone else's rota |
| Data model | Yours | Normalised across vendors | The ATS model, unchanged |
If two or more rows in the right-hand column describe you, the category you have been evaluating is probably not the one you need. That is worth knowing before a procurement cycle, not after.
Where does the category go from here?
Toward compliance, which is the pressure that will most likely settle the vocabulary.
The EU AI Act names recruitment, selection, targeted job advertising, and candidate evaluation as high-risk uses, with deployer duties covering risk assessment, technical documentation, bias testing, human oversight, and transparency. The phasing changed in July 2026. Employment sits in Annex III, and the Digital Omnibus pushed that whole category's main obligations out to 2 December 2027 — a year and a half of breathing room that the transparency duties, still due 2 August 2026, did not get (Hunton, Aug 2026). Whatever moves candidate data between systems becomes something you have to describe in writing, per channel, and keep current.
At that point the difference between a library your team maintains and a connection somebody operates on your behalf stops being a preference and becomes an audit question. A category exists once buyers need a word for the thing they are being asked to document. That is roughly where recruiting connectivity is now.
What to do next
Three questions to answer before your next integration conversation:
- Who owns the connection when it breaks? If the honest answer is a person who also has a hiring target, you are looking at the wrong category.
- Which channel behaviour cannot survive being normalised? Screening question structure and source attribution are the usual answers.
- Would removing the layer be reversible? If not, it has become a system of record, whatever it is called.
Whichever answers you reach, our team is happy to be a sounding board on them. You can also read how the ATS side of the connection is set up.
