Part of the Recruitment Software Guide
Recruitment 30 July 2026 6 min read

Job Board Integration for Recruitment Software: API vs XML Feed

UK agencies post to multiple job boards simultaneously and expect applications to arrive automatically in their ATS. It is not that simple. The main UK job boards do not all give the same API access. A direct connection to each board is too much work, and that is why multi-posting tools exist. The usual faults are also well known. Applications go missing. The same candidate appears twice. Data arrives late. The right set-up stops most of them.

The UK job board landscape and API access

The main UK job boards each have different levels of technical integration capability:

  • Indeed has the most comprehensive API suite. Job Sync API (GraphQL-based), Indeed Apply integration, and Sponsored Jobs API. ATS partners using the Job Sync API see 70% Indeed Apply adoption versus 50% for XML feed-only integrations. When using Job Sync, all public jobs must be sent to Indeed immediately with updates within 15 minutes.
  • CV-Library offers a Job Search API, though it is designed for front-end JavaScript applications rather than bulk data operations.
  • Reed has a public API supporting job search, details retrieval, and job posting.
  • Totaljobs has limited direct public API documentation; it is primarily accessed through multi-posting platforms.
  • LinkedIn has no public Jobs API for another ATS to post through. You can only connect through its approved partner programme, which covers the large ATS vendors.

Connect with us about recruitment software · · Replies within 24 hours

API integration vs XML feed: the actual difference

Both methods get jobs onto job boards. They differ in flexibility, stability, and setup requirements.

Aspect XML feed REST/GraphQL API
Setup complexity No engineering required: configure and submit Developer setup required for authentication and endpoints
Update frequency Typically every hour (batch) Near real-time (Indeed Job Sync: 15 minutes)
Stability High. XML schemas rarely change Lower. API versioning can break integrations
Data fidelity Standardised fields; less flexible More granular: can include custom fields per board
Apply flow Candidate applies on job board site Indeed Apply: candidate applies within Indeed interface

XML feeds use the Rightmove V3 BLM format as the UK standard. It came from the property portals. Job boards and estate agent software both accept it. For most agencies, an XML feed is enough, and more reliable than a direct API connection with every board independently.

What multi-posting tools do

Broadbean, Idibu, and LogicMelon exist because maintaining direct integrations with dozens of job boards individually is impractical for most agencies. They give you one screen from which a job is distributed to multiple boards simultaneously, with response aggregation back into the recruiter's dashboard.

Broadbean posts to 7,000+ job boards and channels. It includes internal and external CV searching, referral programme management, and social media publishing. It integrates with most major ATS platforms via API.

Idibu posts to 1,000+ job boards and social networks through standardised feeds and API support. It centralises job management across all boards from one interface.

LogicMelon focuses on ROI tracking by job board: which boards are producing applications, at what cost, and which sources lead to placements. For agencies paying per-posting fees across multiple boards, this visibility matters.

All three tools charge on a subscription basis and integrate with the major UK ATS platforms. The chain usually runs like this. The ATS posts the job. The multi-posting tool sends it to the boards you chose. Applications come back to that tool. It then puts them on the candidate record in the ATS. Each step is a potential failure point.

The most common integration failures

The failures that agencies report most consistently are:

  • Missing applications: the job board pushes applications to the ATS but the sync logic breaks. Applications sit on the job board unforwarded for days. In competitive roles where candidates are considering multiple offers, a 2-day delay in acknowledging an application can mean the candidate has already accepted elsewhere.
  • The same candidate twice. A person applies for two roles, or was already in the database. The system makes a second record instead of updating the first. The cause is a weak rule for matching people. The system matches on the email address, but not on the name and the telephone number. A person who uses a different email therefore appears twice.
  • Version mismatches: the ATS updates to a new API version; the job board's integration still uses the deprecated endpoint. Jobs stop posting until the ATS vendor or the board updates their integration. This is more common with REST APIs than XML feeds.
  • Authentication failures: incorrect endpoint URLs, missing required parameters, or OAuth token expiry silently break the integration. Jobs appear to post from the ATS side but do not appear on the board.
How to find a fault before it costs you a placement. An agency that posts jobs automatically needs somebody to check the result. That person looks at the boards, at least once a week, and confirms that each live role is there. Integration failures tend to be silent) the ATS shows the job as posted, the board shows nothing. Discovering this when a role has been live for two weeks without applications is significantly more costly than a weekly five-minute check.

Connect with us about recruitment software · · Replies within 24 hours

Why the same candidate appears twice

The duplicate above is worth looking at closely, because it is the whole problem in one place.

No system in the chain knows who a person is. The job board holds one record, the multi-posting tool holds another, and your ATS holds a third. Each one guesses at a match from an email address. A person with two email addresses becomes two people, and nobody can prove which is which.

On engage.re a candidate is a declared record type with a permanent identifier that never changes. Two systems that hold the same person hold the same identifier, so there is nothing to guess. An application from a board joins the record it belongs to, and the system logs it.

That is what interoperability means in practice, and it is why a feed stops being fragile. We explain it in what does an interoperable software market look like. We show how a whole sector builds on one foundation in bespoke software for a whole sector.

What a bespoke integration can do differently

Some agencies post in their own way. Each division may post differently. A career page in the name of a client may feed the boards by itself. A screening step of your own may come before the recruiter sees anybody. A connection built for you can handle all of that. A multi-posting tool cannot. The same holds for an agency that built its own site for candidates. It needs to reach the job board APIs on its own terms, and not through another company.

The cost is development and maintenance time. Job board APIs change, authentication protocols update, and new boards enter the market. A bespoke integration needs ongoing technical maintenance in a way that a subscription to Broadbean does not. A system built to last expects an API to change. Its structure takes a new job board connection without a rebuild.

Sources and further reading

You can see this in a working system. The ESRE live recruitment demo opens with no login, and it shows the job board work in this guide. Sign in as consultant and post the job to boards direct, or as candidate and apply and see the status. It is a working system, not a screenshot.