You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

ATS @ naukri – Sharing responses across systems

0.00 avg. rating (0% score) - 0 votes


To begin with, you should know what is an ATS. An applicant tracking system (ATS) is a software application that enables the electronic handling of recruitment needs
We have a couple of ATSs at
  1. CSM – Apart from offering an advance ATS, CSM (CareerSite Manager) also helps you create career-sites.
  2. EAPPS – EAPPS (Electronic Application Software) is an efficient response/resume management tool to streamline your recruitment process
  3. BRV– BRV (Basic Response Viewer) is a simpler version of eApps. It is also a response management tool but with limited features and comes for *free* with a Job Posting subscription.
If you wish to discover differences among these, please visit Naukri FAQ page.

Apply Integration – Sharing responses across systems:

We call the process of sharing responses across systems as Apply Integration.
Though we always prefer that you as a recruiter, buy one of Naukri’s ATSs. If the recruiters/company has some ATS of their own, we want to send applications to them in their ATS only.
What’s in it for you?
It depends upon who you are. If you are:
  1.  A Recruiter: If you as a recruiter, have got your own ATS and you post a job with Apply Integration on, we will send the applicant responses directly to your ATS.
    The potential of Apply Integration is very well explained in this slide on slideshare.
  2. A JobSeeker: Well, as a jobseeker you would hardly notice any difference between applying to a normal job or applying to an Apply-Integration job. If you apply to a job with apply integration, we send your application details to the company ATS directly. So what does that mean? It means, that the company has got your data and now they can proceed with the recruitment process.


There are many ATSs across the world. Each ATS would provide similar yet very different features. Even in naukri, we have 3 different ATSs, each has its own different features. Each has its own abilities and limitations. As there is not set standard, this leads to following challenges:
  1. Operating System: Each ATS may be using a different OS. Different OS, different set of protocols, different ways to communicate.
  2. Programming Languages/ Platform: People tend to use varied programming languages ranging from open source technologies (PHPPythonRuby) to ASP.NET. Different languages, different powers and different limitations. Here comes another challenge,  developers from different platforms, programming backgrounds and expertise, may find it difficult to communicate due to different usage of terms and concepts.
  3. Input Values: Each ATS may want different set of inputs. They may have some fields which are mandatory at their end, but non-mandatory at Naukri’s end. Or even worse, some fields, which are mandatory at their end but not at all available with us. The names /labels and validations for each field may also be different. Bigger challenge here is how the same set of information is interpreted to be different by different clients, e.g.
Naukri Field Name
Naukri Field Value
Sachin Ramesh Tendulkar
Client1 Field Name
First Name and Last Name
Client1 Field Value
First Name – Sachin
Last Name – Ramesh Tendulkar
Client2 Field Name
First Name and Last Name
Client2 Field Value
First Name – Sachin Ramesh
Last Name- Tendulkar
Naukri doesn’t have any field named first name or last name. First we need to derive these values from our existing field “name”, but with different logic for different clients. A third client may come with even different requirement in the name field only.
There can be n number of examples for this. For some fields, we have free text, i.e. the user may enter more data in these fields. But some clients may not accept this data as such, as they have field length limits. e.g. Address field. Some clients may want address to be split in different fields,: house no., street no., area, region, landmark, address line1, address line2 and so on. But we have a single field for address. So, again we need to derive values for different fields for different clients with different extraction logic.
  1. Input Mapping: There are cases, wherein some clients may ask for ids rather than values. These ids are specific to them, not Naukri. So again, this can’t be generalised. For example:
Naukri Field Name
Naukri Field Value
Client1 Field Name
Client1 Field Mapping
123 if country name is India
456 if it is Russia and so on..
Client2 Field Name
JobSeeker Country
Client2 Field Mapping
11 if Country is India
89 if it is Russia and so on..
  1. Connection Method: Till now, we have encountered following set of connection methods for different clients:
  1. Restful API – Clients expose their restful apis, to which we need to push applications of the candidates who have applied to their jobs posted on naukri.
  2. Chronology in Restful API – Clients may want us to follow a chronology, e.g, first step may be call a login api, followed by a call to actual data sending api and lastly a call to logout api. Clients may follow any logical chronological order of apis they may want.
  3. FTP/SFTP – Clients herein want a file of applications to be uploaded on their server.
  4. Email – Clients herein want a file of applications to be sent to their email id.
With time, we may add more methods here.
  1. Input Format – Different clients may need different input format, e.g. JSON, CSV or XML. We provide all three of these.
  2. Response: Clients may or may not opt to send a response back to us. This response helps us determine whether the application was successfully sent or not. Again, this may be in different formats, different labels, different codes, different interpretation of different codes.
  3. Frequency of push: Some clients want applications real time, some may want once a day or after some fixed interval of time.
I hope by now, you would be able to understand the complexity of the system to some extent. We want to build a system so generic, that we need to do minimal configuration changes for integration with any client.
Continue to part2 of the series ATS @ naukri – Solution and Architecture.
Posted in Web Technology