Naukri posting and database search, built for Indian resume formats

Buyers usually say Naukri integration and mean one of two very different things. The first is posting: a requisition published to Naukri, applications coming back into the CRM. The second is database search, the Resdex-style pattern of searching a large candidate database directly and pulling matching profiles into your own system. They have different access terms, different pricing and different technical shapes.

Posting is the simpler of the two and is scoped first. A requisition written once in Surhires, published out, with applications returned as candidate records that parse and deduplicate on arrival, source recorded, and the applicant landing on the requisition rather than in an inbox.

Database search is the one that changes how a desk sources, and it is also the one with the tighter commercial terms. Searching a licensed database from inside your CRM, seeing which results you already hold, and pulling only the genuinely new ones is a materially different day from searching in one tab and pasting into another. Scope here follows what partner access permits, and we will describe it accurately once we know what that is.

A resume written for the Indian market frequently runs three to six pages and follows conventions that Western-trained parsers handle badly. Education appears in reverse-chronological detail with institution, university affiliation, year and percentage or CGPA. Employment history often lists every project inside a role, with client name, duration, technology stack and the candidate's specific responsibility on each one. Personal details appear at the end. Notice period is stated explicitly and is decisive.

A parser tuned for a two-page US resume flattens all of that. It reads the project list as one long job, misses the notice period entirely, and treats a percentage as a stray number. What you get is a record that looks populated and is wrong in the fields that decide whether you call the person.

Surhires parses the structure rather than the first two pages. Project blocks are separated from the parent role, so a candidate with five projects inside one employer is searchable on all five technology stacks. Notice period is a first-class field because in this market it is the field that determines whether a candidate can start when the client needs them. CTC and expected CTC are captured as separate values with their currency, because the gap between them is the negotiation.

Two fields shape an Indian recruitment desk more than anything else. The notice period, which can be sixty or ninety days and which quietly decides whether a submittal is even viable against a client's start date. And CTC, current and expected, which is the language the whole negotiation happens in.

Both are structured fields rather than notes, which means both are searchable, filterable and reportable. A recruiter can ask for candidates available within thirty days at an expected CTC inside a band, and get an answer instead of a list to read through. A manager can see how many live submittals sit against candidates on ninety-day notice, which is a forecast rather than a hope.

The Placement Risk Agent watches notice-period signals on live offers and flags one that is drifting, which is a genuine problem in a market where a ninety-day gap gives a counter-offer plenty of time to arrive.

Surhires is operated by Soor LLC, a Delaware company, and the Wave 1 markets are the United States, the United Kingdom and Australia. India is a Wave 2 market. That is a sequencing decision about pricing, support hours, payment rails and local commercial terms rather than a judgement about the market, which is enormous and underserved by expensive Western tooling.

It does mean the Naukri connector is not competing for the front of the queue against Indeed and ZipRecruiter, and pretending otherwise would set a delivery expectation we would then miss. What is already true is that Indian resume formats, notice period and CTC handling, WhatsApp-native candidate communication and DPDP Act consent and portability support are built into the product rather than bolted on for a later market.

So a desk in Bengaluru or Hyderabad can run Surhires today. The Naukri sourcing leg is manual until partner access is confirmed, and the rest of the system was designed with this market in the room.

Download profiles from your Naukri seat as you do now and bulk import them. Parsing, structuring, duplicate detection and talent-pool assignment all run on upload, so a morning of sourcing becomes a set of structured records rather than a folder.

Post on Naukri directly and route the application emails into a requisition inbox, with the source set on the ingest rule. Attribution then works from day one, and the report showing which source produced placements rather than applications is available before any API exists.

Nothing here is throwaway work. When partner access is confirmed the ingest path in front of the database changes; the database, the sources, the pools and the history do not.

Candidate data held in India sits under the Digital Personal Data Protection Act, and the product supports notice and consent records against candidate profiles along with portability export. That is a capability statement, not a certification: you remain responsible for the lawful basis on which you hold and contact a candidate.

Consent basis, when it was captured and through which channel are stored on the record, and retention windows can flag dormant records for review or erasure. When a candidate asks what you hold, the answer comes from the record rather than from a search of six inboxes.