Welcome to the second part of the three-part series dedicated to ATS integrations for job boards (first part: Introduction to ATS Integrations for Job Boards Part 1 / 3). In this part, I will explain the basics of ATS integrations for getting jobs, submitting applications, and getting application status from the perspective of a job board. 

What are the advantages of integrating a job board with an ATS?

Why do job boards want to integrate with ATS? The industry's holy grail has been an unattainable goal for many years.  

The most straightforward explanation is that job boards increase conversion rates against customers through an ATS integration and improve the user's UX. There is no need for a click-out, so the job board gets to keep the job seeker on their site, capture their data and send them job alerts.  

However, the real ATS integration is the only way to prove that an application has happened on the job board (unless it hosts it). An integration can give job boards feedback on candidate quality and help them adjust traffic acquisition strategies. 

 All of this causes an improvement in the bottom line. 

How can job boards integrate with an ATS?

As discussed in the previous section, job boards and ATS platforms can integrate in multiple directions: the most common ones are for getting jobs or delivering applications. 

Theoretically, there is also an integration where job boards could get the status of a submitted application. Still, this is hard to build for various reasons, which I will explore later.

In reality, the integration related to getting jobs is less crucial than most ATS platforms can be scraped. The cost of scraping an ATS for one year is significantly lower than the cost of building and maintaining an integration.

The integration related to delivering applications to the ATS is the most important, and we will discuss it in this post. 

How can job boards deliver an application to an ATS?

Generally, there are two ways to deliver an application into an ATS (for the scope of this post, I will only focus on delivering what is called a “full application,” not a lead (name, email, CV). 

This is important, as ATS platforms and recruiters treat “leads” (i.e., incomplete applications) differently. Depending on the company, they could be discarded or placed in a different flow that requires a manual process from the recruiter. 

The first option occurs when the ATS is “aware” of your delivery. This is most known as an ATS integration, which uses the ATS's API endpoint to deliver the application. 

The second option involves using humans, automation (RPA) or a combination of both without the ATS's knowledge. 

ATS Integrations for Job Boards via API

Job boards can indeed build integrations to ATS platforms alone. Here is what the process of getting jobs and submitting applications via API integration looks like: 

Getting jobs and apply schema

In short, the job board needs to pull a list of jobs from the ATS, import them and then use the ID for each job (usually part of the URL) to pull the application schema.

The application schema contains all screening questions the job seeker must answer to apply.

Apply Submission

Once the job board collects the application screening questions the employer requires, the apply object can be submitted to the ATS.

Some ATS platforms require that the user create an account. This is an additional complication, as the job seeker must be notified about this (and/or verify the email).

Getting apply status

Now that the job board has successfully applied, the status can be checked via the external_apply_id, which references the ATS.

As you can see, this is a very cumbersome and complex process. We have not even had the chance to discuss conditional screening and knock-out questions.

This is only if you want to integrate one ATS. Imagine that you want to integrate with 20.

Vendors in the ATS integration space

There are two types of players in the market, depending on which side of the market they service: the employer and the job board. 

Jobsync, the company I saw built from scratch in 2019-2020, takes a more targeted approach to employers. Initially conceptualized as a tool that brings applicants to the job board to increase their application conversion rates, the company has evolved a lot.

Jobsync is currently marketed as an operations platform designed to rightsize the applicant volume so employers can achieve their hiring goals.

Soon after, companies like Merge and Kombo emerged. They are slightly different, as they promise to offer a unified API for communicating with multiple ATS platforms, but they target job boards. 

To keep the example simple, if one ATS uses “first_name” and the other one uses “firstname” for the First Name field, these “connectors” unify the process. 

Here is what the data flow looks like for the job acquisition and apply schema part:

Similarly, here is the process on submitting an application / getting the apply status:

You have probably seen the red "Authentification" box by now. Red usually means danger, and this is no exception.

The complexity of this approach is that, in most cases, you need authorization to apply to the ATS. Scalability becomes an issue from the job board’s perspective because you have to onboard every ATS separately. 

The larger the employer, the more challenging it is to obtain these API keys because of the number of stakeholders involved (IT security, HR, external development companies).

Additionally, the exact ATS implementation is rarely found in two different companies, which means there will always be some form of customization, even if the core layer of the API is unified.

Besides that, the way these integrations work from the job board perspective is pretty straightforward:

1. Your client (the employer) authorizes you (usually an API key) to post applications to their ATS
2. With every job posted on your site, you use the ID from the ATS URL to pull the application schema via API.
3. You use the apply schema to build an application form on the job ad page of your job board
4. Once you collect the application information, submit it via the API to the ATS. 

Again, I am oversimplifying this. Conditional questions take a lot of work to build in the front end. Apply schemas often change, and no integration is safe from a recruiter adding a new field you did not map the first time.

Apply Delivery without an Integration to the ATS

The second option is when someone (or something else) fills out the application form for the candidate on the target ATS without explicit knowledge of the ATS.

There are two types of vendors out there:

1. RPA providers that explicitly use only technology to submit applications to the ATS (a mixture of scraping and automation)
2. Other providers use a mixture of humans and basic RPA to assist the human applying the candidate.

In the last part of the series, I will review the different RPA vendors and discuss the risks of each approach.

Use the form below to subscribe to get notified when the last part of the article is published.