Automating LinkedIn Recruiter When There Is No API
Sep 3, 2026
LinkedIn Recruiter has no public API and punishes seat sharing, so the usual integration approach fails. How we ran overnight sourcing for a recruitment agency by giving an agent a desktop and a browser.
A recruitment agency in London asked us for something their CRM vendor could not sell them. They wanted their candidate sourcing to continue after their consultants went home.
The obvious version of this is an integration. Their CRM is Bullhorn, which has a documented REST API, so writing candidates and notes into it is ordinary software work. The problem is that Bullhorn is where sourcing ends, not where it happens. Sourcing happens in LinkedIn Recruiter, and LinkedIn Recruiter has no public API.
That is not an oversight to be worked around with a support ticket. There is no partner programme that opens up Recruiter search to a third party the way the Bullhorn API opens up a CRM record. If you want a machine to run a Recruiter search, the machine has to use Recruiter, in a browser, the way a person does.
Two constraints that shape the whole design
No API means the browser is the interface. Anything the system does in Recruiter, it does by loading pages and clicking. There is no shortcut layer underneath.
A Recruiter seat does not like being used twice at once. Seats are licensed per named user, and simultaneous sessions from two places get treated as account sharing. Consultants notice this already when they log in from a second device. So an agent working the account while its owner is also working it is not a performance problem to tune. It is a design constraint that rules out the concurrent model entirely.
Those two together explain why this had not been solved with the tools the agency already owned. Their workflow automation platform could not reach into Recruiter, and anything that could reach into Recruiter would collide with the consultant using it.
Giving the agent a computer
Helix runs each agent on its own Linux desktop, a container with a real graphical environment and a real browser. We built this for coding agents, so that an agent could run an IDE and a test suite and see what it was doing. The recruitment work uses the same thing for a different reason: a desktop is a general-purpose interface to software that has no other interface.
The desktop is shared. A person connects to it through their browser and sees what the agent sees, with the mouse and keyboard available. That turned out to matter more than the automation. Setting up a search is not a task you can specify well in a prompt, because the criteria that make a candidate right for a brief are mostly tacit. A consultant sitting on the same desktop, running the search themselves once while talking through what they are looking at, transfers more than an hour of written instructions would.
The night shift
The seat constraint has one clean answer, which is to take turns.
At the end of the day the consultant hands their Recruiter session over to the agent desktop. The agent then has the account to itself for the hours nobody is using it. It works the live searches, opens profiles, screens against the brief, and writes outreach drafts.
The output is not a report. It goes back into the tools the team already opens first thing: candidates land in a LinkedIn Recruiter project, drafts sit against them, and the structured records go into Bullhorn through its API. A Slack channel gets a message when a batch is delivered. In the morning the consultant opens Recruiter and finds a project that was empty when they left.
Nothing is sent. Every draft waits for a human to read it, change it, and press send.
The feedback we did not expect
The first thing the agency told us after a week was that it was keeping them busier.
We had been prepared to defend a time-saved number. What actually happened was that the bottleneck moved. Sourcing had been the constraint, so the pipeline was shaped by how many profiles two delivery consultants could get through. Once sourcing ran overnight, the constraint became the number of real conversations the team could have the next day, which is the part of the job they are paid for.
For an agency whose model is high-touch, that is the trade they want. For one running volume outreach with minimal human contact, it is not, and the honest answer there is that a cheaper sequencing tool does that job.
What this costs you
A human is in the loop on every message, so review capacity is the new ceiling. The agent can draft faster than a consultant can approve. Past a certain point you are queueing work for people rather than removing it, and the system stops helping.
Browser work is slower and more brittle than an API. A REST call either succeeds or returns an error. A page load can succeed and be the wrong page. The agent has to check that it is where it thinks it is, and interfaces change without notice, so this needs maintenance in a way an API integration does not.
Recruiter's terms restrict automated access. LinkedIn's User Agreement prohibits using software, scripts or bots to access the service or extract data from it, and Recruiter sits under a separate commercial contract on top of that. Running an agent on a licensed seat outside working hours is not the same as scraping profiles at scale from an unlicensed account, and it is also not obviously permitted. Read your own Recruiter contract and decide with your legal adviser. We are not going to tell you it is fine.
Candidate data is personal data. Sourcing produces CVs, contact details and notes about identifiable people, and the agency is the controller for all of it under UK GDPR. This is one reason the whole system runs on the agency's own infrastructure with models running locally. It is also why the human approval step is not only a quality control: automated decision-making about people carries obligations under Article 22, and the EU AI Act classifies worker-selection systems as high risk.
Where this generalises
A category of work here was blocked on the absence of an API, and the absence of an API stopped being a blocker once the agent had a screen.
Most companies have at least one system like Recruiter: load-bearing, used all day, and closed. The usual advice is to replace it with something integrable, which is a migration nobody wants to run. Driving it in a browser instead is less elegant and available immediately.
The architecture — Virtual Desktops for AI Agents, on why each agent gets its own machine.
For agencies — Recruitment Agencies, covering sourcing, business development, contract desks and internal hiring.
The handover pattern — Follow the Sun, the same shift-change problem in distributed engineering teams.
Talk to us — Get in touch about a pilot on one desk.