Element now has an API: recruitment that plugs into your own systems
Element now has a public API, in its v1-beta version. That means a client’s IT team or their integrator can connect our recruitment system to their own tools: a form on the career page, an internal HR dashboard, a data warehouse or an automation platform. A candidate added in one place shows up in the other, and a stage change in Element lands wherever the client needs it, with no manual re-typing. Behind that interface sit roughly 10,000 lines of code that came together in six weeks of my work with a language model. As always, I’ll point out that I’m not a programmer.
This is the next chapter after Element’s mobile views, which I shipped just a few days earlier. The whole series started back in September 2025 with a claim I keep repeating to clients in my workshops: someone without an engineering background can deliver a serious feature together with AI, as long as they keep the discipline and have someone watching over their shoulder. This time the test was the API, the most technical part of the entire system.
What the API actually gives recruitment-system clients
An API is a set of doors other programs use to talk to Element without a human clicking around in the panel. Until now recruitment data lived mostly inside our system, and every exchange with another tool meant an export, an import, or a request to us to build a specific connection. A public API flips that dependency, because the client decides what connects to what, and does it at their own pace.
In practice this opens a few scenarios recruiters have waited for the longest. An application form on the company career page can create a candidate in Element automatically, with no copying data out of an email. A stage change in the process can update an internal board report or a dashboard in the BI tool the HR team uses. Recruitments and their statuses can be wired into no-code automation platforms, so even a team without programmers can assemble its own flow. Each of these used to require work on our side, and now sits with the client and their integrator.
The v1-beta version exposes 12 endpoints, the individual addresses for specific operations: fetching and creating candidates, listing recruitments and their stages, and reading statuses. We deliberately started from a core that covers the most common integration needs, instead of mirroring the whole panel from day one. For a client team that manages its data in our ATS, that predictability matters most: a stable, documented set of operations you can build integrations with Element on.
10,000 lines of code in six weeks and 21 pull requests
The project closed in six weeks, around 10,000 lines of code and 104 commits, the changes saved one after another. I opened 21 pull requests, the packages of changes handed to a shared repository; 17 of them made it into the system, and 4 I deliberately closed when I narrowed the project’s scope. The code is in production in beta mode, which means I intentionally invited the first users in before I call it fully mature.
What went wrong and what it taught me
The most valuable part of this project is not what worked right away, but the three moments where I had to step back:
Who actually performs the action?
At the start I designed API access around an abstract integration key. It felt natural, because it’s a program talking to the system, not a specific person. A reviewer from the dev team showed me the gap: every operation through the API still has to be tied to a real user with real permissions, otherwise we lose the audit trail and there’s no telling who changed a candidate’s data, and on whose behalf. After three weeks I rebuilt the foundation so that a concrete user stands behind every action. I was sold on my first idea; someone with more experience showed me where I was wrong, and that was the best hour of conversation in the whole project.
We cut two endpoints instead of shipping everything
About halfway through I cut two endpoints from the plan, the ones meant to handle fully configurable application forms and the answers in them. They looked good on a feature list, but in v1-beta they added complexity without a proportional payoff for the first integrations. Closing those four pull requests was a decision, not a failure. Better to ship a coherent core that clients will actually build connections on than to tick off every item on the original list and put out an interface nobody can get their head around.
Automation does not replace code review
Near the end of the project, several versions of the code that had grown side by side were waiting to be combined. I used a tool that was supposed to merge them into one coherent whole automatically. It worked, but along the way it quietly deleted a few of my earlier fixes and duplicated another fragment. It is a bit like a tool for merging several versions of a document cutting two paragraphs and copying a third on its own, without asking anyone, and then presenting the file as finished. That is exactly where the problem sits: nothing reported an error, because from the outside everything looked done. A human caught it, someone who sat down and read the result line by line. It is the best illustration of the boundary I talk about in every workshop: AI and automation speed the work up brilliantly, but they do not take responsibility for whether the result is correct. Someone awake has to look at the output.
On top of that came a small thing that beta testing is exactly for. On launch day a quick test caught an inconsistency in how the API returns the message for a malformed request. I fixed it the same day. Beta with real integrations finds real bugs faster than any test plan at a desk, and that is precisely why I ship it early instead of hiding the code in a drawer until it is perfect.
What this means for teams without their own IT department
The line between an idea and a deployment is moving faster than many companies have noticed. Not long ago an API was engineers-only territory, and today the person managing the product can deliver one, as long as they work with a language model deliberately and hand the code to a senior developer for review (thank you, team!).
What does working with the model deliberately mean? From my perspective it means working in small steps, ready to undo a bad architectural decision, starting from a plan and ending with the implementation and full coverage by automated and manual tests.
Frequently asked questions
What is Element's API and what is it for?
It is a public interface other programs use to connect to the ATS system and exchange data with it without clicking around in the panel by hand. It is for integrations: creating candidates automatically, reading recruitments and their stages, and passing statuses to the client’s other tools.
Do you have to be a programmer to use the API?
On the implementation side, yes; the client’s IT team or an external integrator puts the integration together. Some of the simpler scenarios, though, can be built on no-code automation platforms, without writing code from scratch.
Is the API stable yet?
It runs in production in its v1-beta version. The core is ready and documented, but I deliberately call it beta, because the first real integrations are still giving me signals that tighten the details.
Did AI really write the API code?
The code was generated by a language model under my direction and under the dev team’s review. My role was running the project, the architectural decisions and catching mistakes, not typing out lines by hand.
If you run recruitment and have an integration in mind that you couldn’t pull off until now, this is a good moment to revisit the idea. And if you’re curious how features like this get built without a dedicated team of engineers, take a look at the earlier posts in the vibe coding series.
DISCOVER ELEMENT!
Maciej Michalewski
CEO @ Element. Recruitment Automation Software
Recent posts:
Element now has an API: recruitment that plugs into your own systems
Element now has a public API (v1-beta). I explain what integrations give recruitment-system clients, the mistakes I made and what they taught me.
Recruiting from your phone: Element is now mobile, built by AI
Element’s mobile views are in production. Recruiters and hiring managers now run the process from a phone, and AI wrote 15,000 lines of code in five weeks.
You get an email from AI instead of a human, problem?
Getting an email from AI instead of a human is fine, as long as the data stays high quality. Most routine work is algorithmic, and the outcome matters more than the author of the message.
The AI job apocalypse is a fantasy, says a16z. But Poland?
David George of a16z says the AI job apocalypse is a fantasy. I test his thesis against Polish data and a fresh vibe coded experiment of my own.
Vibe Coded Element x LinkedIn integration is live: project recap
LinkedIn approved Element’s public XML feed, fully built in vibe coding mode with Claude Code. What that means for people who don’t write code.
danehr.pl: a new data hub for the Polish labour market
Polskie Forum HR has launched danehr.pl, a portal that gathers employment, wages, unemployment and labour market reports in one place. Element is the technology partner of PFHR and feeds one of the portal’s sections.
