Candidate Sourcing API: A Builder's Guide

A candidate sourcing API is an HTTP endpoint your product calls to find and pull candidate profiles out of external talent pools and into your own pipeline. You send a query, such as a role, a set of skills, or a location, and you get back candidate records as JSON, the interchange format standardized in IETF RFC 8259, so your code can store, filter, and route them however your product needs. The word that matters is sourcing: this is the step that decides who even enters your funnel, long before anyone scores or shortlists a candidate.

The reason builders care about this layer is demand. In November 2025 there were 7.1 million job openings in the United States, per the U.S. Bureau of Labor Statistics Job Openings and Labor Turnover Survey. Every one of those openings is a pipeline someone has to fill, and the products that fill them need a programmatic way to reach candidates at that scale. Intelligent sourcing has moved from a differentiator to an expectation: in its 2025 Talent Trends research, a survey of 2,040 HR professionals, SHRM found that 51 percent of organizations using AI in HR apply it to recruiting, with common uses including automating candidate searches, per SHRM's 2025 Talent Trends report.

Sourcing is easy to confuse with the two layers next to it, so it helps to name what each one does. Sourcing answers "who is out there and can I bring them in." Parsing answers "what does this one candidate's document actually say," which is the job covered in the resume parser API guide and the CV parsing API guide. Matching answers "how well does each candidate fit this role," the job covered in the embeddable candidate matching API guide.

The order is what makes them distinct. Sourcing runs first and produces a raw pool. Parsing then turns each messy profile or resume in that pool into structured, queryable fields. Matching runs last and orders the parsed candidates against a specific job. A matcher with nothing to rank is useless, and a parser with nothing to parse is idle, so sourcing is the input that keeps both of them fed. Build or embed it badly and everything downstream starves.

A sourcing API is only as good as the pools behind it, so the first thing to evaluate is what it can reach. In practice the data falls into three broad kinds. Job-board and application data is candidates who have actively signaled they are looking. Resume and profile databases are stored candidate records, often built up over years, that you query rather than wait for. Public web and social signals are profiles and activity that exist openly online and can be collected and refreshed over time.

Each kind trades freshness against coverage and against compliance risk, and the shape of the data you get back differs too. Some sources hand you a clean structured record, others hand you a raw document or an HTML profile that still needs a parser before it is useful. That is the seam between this layer and the next one: a good sourcing integration tells you clearly which fields are populated and which are raw, so you know what still has to pass through parsing and enrichment before it can be matched.

The search call is the easy part. The real engineering in sourcing is moving large volumes of records without losing them, duplicating them, or getting throttled. Rate limiting is the first wall you hit. The standard signal is the 429 status code, defined in IETF RFC 6585, which indicates the client has sent too many requests in a given amount of time. RFC 6585 says the response should explain the condition and may include a Retry-After header telling the client how long to wait. Your sourcing client has to treat a 429 as a signal to back off and resume, not as a hard failure.

Pagination and transport behavior are governed by the same HTTP semantics every API shares, set out in IETF RFC 9110 (2022), which defines the status-code classes you should expect, 2xx for success, 4xx for a bad request, 5xx for a server fault, and which methods are safe and idempotent. A sourcing read has no side effects, so design your client so a page request can be safely retried after a connection failure, as RFC 9110 allows, without pulling the same candidates twice or skipping a page.

Pull from more than one pool and the same person shows up more than once, with a different name spelling here, a stale job title there, and no shared identifier anywhere. Collapsing those into one candidate is not a string-equality check, it is record linkage: a statistical decision about whether two records refer to the same real-world person. The foundational framework is Fellegi and Sunter's A Theory for Record Linkage (Journal of the American Statistical Association, 1969), which compares records field by field and classifies each pair as a match, a non-match, or a case for human review.

That three-way outcome is the part worth designing for. Exact duplicates are easy and clear non-matches are easy, but the ambiguous middle, two records that might be the same person, is where a sourcing pipeline either quietly merges two different candidates or splits one candidate into two. Both errors corrupt the pool your matcher later ranks. A sourcing layer that takes deduplication seriously exposes a confidence on each merge and keeps the uncertain cases reviewable, rather than forcing every pair into match or non-match.

Sourcing is where personal data enters your product, so it is where data-protection duties begin. On access, the US position was shaped by hiQ Labs v. LinkedIn, where the Ninth Circuit held that scraping publicly accessible data likely does not violate the Computer Fraud and Abuse Act, because a public page is not accessed "without authorization," per the Ninth Circuit opinion (31 F.4th 1180, 2022). That case was later resolved on contract and tort grounds, so CFAA access is only one piece of the risk, and it says nothing about what you may then do with the personal data. Where you collect from the open web, remember that the Robots Exclusion Protocol, standardized in IETF RFC 9309 (2022), is advisory guidance for crawlers and not an access-control mechanism.

Data-protection law is the bigger obligation. Under the EU General Data Protection Regulation, when you obtain personal data from a source other than the individual, which is exactly what sourcing does, GDPR Article 14 still requires you to inform that person, including telling them the source the data came from and whether it was a publicly accessible one. And because a sourced pool usually feeds selection, note that AI intended for the recruitment or selection of candidates is classified as high-risk under Annex III of the EU AI Act, Regulation (EU) 2024/1689.

Building sourcing yourself means maintaining connectors to many pools, a resilient client that handles rate limits and resumable pagination, an entity-resolution step for deduplication, and provenance tracking for compliance, all before a single candidate reaches your product's core features. For most teams that is the wrong place to spend engineering time. The pragmatic path is to embed the layer through an API and keep your effort on what your product does with the pool once it has one.

RecruitAI Suite provides the pieces that sit around sourcing. The Data Enrichment API fills gaps in a sourced profile with validated employment and contact data, the Resume Parser API turns the raw resumes and documents you collect into structured JSON, and the Candidate Matching API scores and ranks the pool against a role with semantic matching rather than keyword search. ATS, CRM, and marketplace teams can see how these compose on the job boards solution page, and the applicant tracking system API guide covers writing the results back into a system a customer already runs.

If you want to walk through how a sourcing-to-matching pipeline would fit your platform, you can book a demo and we will set you up. You can also browse the full product list to see how each API composes into a complete recruiting stack.