HR and recruitment

A filled vacancy stays on your careers page for weeks, because two systems both call themselves the careers page

A vacancy gets filled on Tuesday. It disappears from Recruitee's own hosted careers page within seconds — that part works fine. It stays live for another three weeks on the company's actual website, because somebody has to remember to go and delete it a second time, on a page that looks nothing like the one Recruitee generated and was never told the job existed.

Most companies using Recruitee, now Tellent after the 2024 acquisition, do not want candidates landing on jobs.recruitee.com. They want their own careers page, in their own design, on their own domain — and building that well means the vacancy data has to move, not get copy-pasted.

  • REST API with personal API tokens, plus webhooks
  • Vacancies out, applications back in
  • From €1,700 plus service fees
The tool

What Recruitee/Tellent is, and why the careers page is the real project

Recruitee is an applicant tracking system: vacancy management, a pipeline per role with stages you configure yourself, candidate profiles, interview scheduling, and a hosted careers site generated automatically from whatever is open. In 2024 the company was acquired by Tellent and the product is being rebranded under that name, though the underlying platform, its API and most of the interface people already know have carried over unchanged — a company running Recruitee today and one running Tellent tomorrow are very likely running the same thing.

The API is a documented REST interface authenticated with a personal API token, covering offers (vacancies), candidates and their pipeline stage, plus webhooks that fire on the events that matter — a new application, a stage change, an offer being closed. That last one is what makes a real-time careers page possible instead of a page that refreshes once a day and hopes.

The use case we build for most often is exactly the one implied above: a client does not want their own brand disappearing behind a generic hosted careers page, so the vacancies get pulled into the actual website, styled like everything else on it, and applications get pushed back into Recruitee/Tellent as candidates so recruiters keep using the tool they already know. The ATS stays the ATS; the front door just stops looking like somebody else's product.

What goes wrong

Three things that go wrong between a careers page and Recruitee/Tellent

Not hypotheticals. These are the three we find almost every time a company has built its own careers page next to Recruitee without a real connection between them.

The careers page is a museum

A vacancy is closed in Recruitee the moment the offer letter goes out, and stays open on the company's own website for weeks, because someone has to copy the "closed" decision across by hand to a page that is not talking to the ATS at all. A candidate applies to a role that no longer exists and gets an awkward rejection two weeks later instead of never seeing it.

What you see instead

A webhook on the offer-closed event pulls the vacancy off the website within minutes, and one opened in Recruitee appears on the site with the right title, location and hours just as fast.

The vacancy is invisible to Google for Jobs

A custom-built careers page that just displays vacancy text, without the structured data Google requires, never appears in the jobs carousel at the top of search results — free, high-intent traffic that a paid job board listing would otherwise have to buy. Most companies that build their own careers page do not realise this is the trade-off they made.

What you see instead

Every vacancy pulled from Recruitee/Tellent renders with the JobPosting structured data Google for Jobs requires, generated from the same fields — title, location, salary indication where given, closing date — so it shows up without a second content system to maintain.

A branded application form never reaches the recruiter

A company builds its own, better-looking application form because Recruitee's own one does not match the site's design, and the form just emails the CV to HR instead of creating a candidate. The recruiter now checks two places — Recruitee for anything that came through the old route, an inbox for anything that came through the new one — and a CV forwarded late is a candidate who has already accepted somewhere else.

What you see instead

The branded form posts through the API as a new candidate on the right vacancy, CV attached, landing in the same pipeline as every other application. One place to check, whichever form the candidate used.

The bill for doing it by hand

What a careers page that does not talk to Recruitee/Tellent costs

The visible cost is small and repetitive: someone opens the website's CMS every time a vacancy opens or closes and edits it there too, maybe fifteen minutes a role. At a company with 25 open roles a year that is roughly six hours annually — not the point.

The point is what that delay costs in applications. A closed vacancy that stays live invites applications you cannot use and have to reject, each one a small hit to how a candidate remembers your company. A vacancy missing from Google for Jobs for even two weeks after opening is two weeks of free search traffic that went to a competitor's listing instead, on a channel candidates increasingly use before they visit any job board at all.

What we build

We build the thing on the other end too

With Recruitee/Tellent the connection is almost never the whole job: what a client actually wants is a careers page that looks like the rest of their site and performs in search, and the API feed is what makes that possible without a second content system.

A connection needs two ends. Plenty of agencies will build you the API call and hand you a JSON payload; that is the easy half. The harder half is what the data lands in — a website, a webshop, a portal your customers log into, an internal tool that replaces a spreadsheet. JKC builds both ends, which is why the connections we build tend to keep working: nothing about the receiving side is a black box to us.

API integrations

The connection itself: authentication, field mapping, rate limits, retries and a queue that survives the other system being down for an hour. Built against the documented API where there is one, and against whatever the vendor really offers where there is not.

Websites

WordPress sites that read from your systems instead of repeating them by hand: a careers page fed by your HR system, a team page that follows your payroll, prices and availability that are the real ones.

Webshops

WooCommerce shops where the order is the last time anyone types it: it becomes an invoice in your accounting package, a label at your carrier, a stock mutation in your warehouse, and a line in your CRM, on its own.

Web applications

When the process does not fit any standard product: a customer portal, a quoting tool, a planning board, a dashboard that reads three systems at once. Built on your data, with your systems as the source instead of a copy of them.

What can be connected

What can be connected between Recruitee/Tellent and your website

Built against the REST API with a personal API token, and webhooks for the events worth reacting to immediately rather than polling for.

  • Open vacancies, with the full listing text

    Title, department, location, hours and the complete description onto your own careers page, styled to match the rest of the site instead of the vendor's hosted template.

  • Applications as candidates, CV attached

    Whether submitted through a branded on-site form or a straightforward embed, every application lands in the right pipeline with the CV and cover letter attached, so recruiters never check a second inbox.

  • Structured data for Google for Jobs

    JobPosting schema generated from the same fields as the listing itself, so a vacancy is eligible for the jobs carousel without a second place to keep it accurate.

  • Pipeline stage, for a candidate status page

    A candidate checking where their application stands, read from the actual pipeline stage in Recruitee/Tellent rather than left to guess after a week of silence.

  • Referral source, tagged on the candidate

    Which page, campaign or employee referral link an application came from, tagged as a candidate field so recruitment marketing can see what is actually working, not just how many applications arrived.

A first project is almost always the vacancy feed and the application form together — the two halves of a working careers page. The status page and referral tagging tend to come later, once the basics have run cleanly for a while.

How it works

How a connection gets built at JKC

The same four steps every time, whichever tool it is. Nothing here is a workshop you pay for: step one exists because scoping a connection wrong is the single most expensive thing that can happen to it.

  1. 1. We look at what is actually being retyped

    Not "which fields exist" but "which fields does somebody currently move by hand, how often, and what breaks when they get it wrong". Most projects turn out to need two or three flows, not a full two-way sync of everything. That conversation is what keeps the quote where it is.

  2. 2. We pick the route, and say why

    A maintained connector from the vendor, a platform like Make or Zapier, or a custom integration against the API. Cheapest first, not custom first: if a supported plugin does exactly what you need, that is the answer and we will tell you so. Custom is for the cases where the off-the-shelf option would need so much configuring that it becomes the fragile option.

  3. 3. We build it to survive the other system

    Every connection ships with retries, a queue and an idempotency key, so an order that arrives while the other side is down is delivered later rather than lost, and a retry does not create a second invoice. On a test environment first where the vendor offers one, so the first thing your real administration sees is a working connection.

  4. 4. We hand it over with the failure modes written down

    Which alerts you will get, what each one means, what to do about it, and who to call. Plus the credentials in your own name, in your own vault — not in ours. A connection nobody but us can maintain is a connection you do not own.

More about system integrations at JKC

After it goes live

A connection that fails silently is worse than no connection

This is the part most quotes leave out. A connection that stops working without telling anyone is worse than manual work, because with manual work at least somebody notices when it does not get done. Every connection JKC builds is monitored, and the monitoring is not an upsell — it is in the service fee.

An alert per failed message, not a monthly report

A message that does not get through raises an alert the same hour, with the record it was about. Not a dashboard you have to remember to look at.

Replay, not re-enter

Anything that failed sits in a queue and can be sent again once the cause is fixed, in order. Nobody goes back through yesterday to find the four orders that did not land.

We watch the vendor's changes, so you do not have to

APIs get versioned, deprecated and rate-limited. When a vendor announces a change that affects your connection, adjusting to it is part of the service fee, not a new project.

What it costs

From €1,700, and the biggest variable is who built the other end

For Recruitee/Tellent specifically: because the real deliverable is usually the careers page itself, this tends to be scoped and quoted as a small website project with a connection inside it, rather than a connection with a page attached — the split of cost between the two follows from what the page actually needs to look like.

A connection starts from €1,700 plus a monthly service fee, which covers the monitoring, the queue and keeping up with the vendor's API changes. Work outside a fixed scope is €95 per hour.

What moves the number is not the tool — it is how well the system on the other end is known. If JKC built your website, your webshop or your web application, we already know its data model, its edge cases and where its stock numbers really come from, and a connection into it is mostly configuration and testing. If it is a system we have never opened, we start with a short technical check of both sides and quote after that, so you are not paying hourly for us to work out the basics.

Two more things that move it, in our experience more than anything else: whether the tool has a real API or only a CSV export, and whether the sync has to go both ways. One-way is roughly half the work of two-way, because two-way means deciding, per field, which system wins when they disagree — and that decision is the expensive part, not the code.

Questions

Frequently asked questions about connecting Tellent (Recruitee)

Effectively yes. Tellent acquired Recruitee in 2024 and is rebranding the product under its own name, but the underlying platform, the API and the account you already log into have carried over unchanged so far. If you signed up as Recruitee, you are very likely running the same system that is now being called Tellent.

We build against whichever API endpoint and credentials your account actually uses today, and update the integration if and when the rebrand changes anything technical — which, so far, it has not.

Often next to this one

Tools that often sit next to this one

Almost nobody connects one tool. These are the ones that come up in the same conversation, either because they sit in the same part of the business or because people ask for the two together.

See all integrations

Free, 10 minutes

Not sure where the manual hours actually go?

That is what the Growth Scan is for. Ten minutes, no sales call attached: you get back where the double work sits, which connection would pay for itself first, and which one honestly would not.

Do the free Growth Scan