Candidate sourcing APIs: build a research queue, not an automatic hiring decision

The useful part of recruiting automation is often the least dramatic: reconcile duplicate records, find the source for a claim and give a recruiter a queue they can inspect. A generated "fit score" can hide all three problems.

A candidate sourcing API can support discovery. It cannot establish that a person wants a new job, that an old title is current or that a missing public portfolio means they lack a skill. Build the workflow around evidence and human review rather than automatic ranking or rejection.

Start with a recruiter-approved role brief

Keep required job responsibilities separate from convenient search filters. A title is a retrieval hint, not proof of competence. Two employers can use the same title for very different work.

Have the responsible recruiter approve which professional sources and fields may be processed, the purpose, retention and contact route. Do not expand the search into personal social activity or private contact databases just because an endpoint exists.

The initial output should be an unordered research queue. The recruiter decides which people to consider and contact. The system should not make employment decisions or infer sensitive traits.

Choose the data operation you actually need

People Data Labs Person Search supports queries over its professional dataset. Its documented response order reflects profile completeness, not suitability for your role. Do not relabel the first records returned as the "best candidates."

The Greenhouse Job Board API describes published roles. Its public job feed is not access to the organization's applicants or an authorization to submit applications on their behalf.

Keep the record small and explainable

research_record_id
source_profile_reference
professional_title_and_employer: value, source, observed_at
role_relevant_evidence[]: requirement, source_url, excerpt
unresolved_questions[]
processing_permission_reference
review_state: pending | reviewed | removed

This schema does not need a universal fit number. A reviewer should be able to see which requirement has evidence, which is unverified and which source may be out of date.

Do not attach an inferred age, nationality, health condition, family status or personality profile. Do not use photos, names or personal posts as proxies for those attributes. A sparse record should remain sparse, not receive a penalty disguised as data quality.

Identity resolution deserves its own review

People share names. Accounts move between employers. A professional profile and a code-hosting username should not be merged on a name match alone.

Prefer identifiers already supplied by the person or present in authorized systems. When two records cannot be reconciled confidently, keep them separate and ask for review. An agent should not improvise an identity relationship to complete a row.

Apply deletion and suppression decisions to derived exports too. A removed person should not reappear on the next run because a second supplier still returns their record.

Use a research-only agent brief

Use the recruiter-approved role brief and permitted professional sources.
Create an unordered research queue with source-linked, job-relevant evidence.
Do not infer sensitive attributes, rank candidates, reject anyone or contact them.
Do not interpret missing public evidence as evidence of missing ability.
Keep uncertain identity matches separate for human review.
Use only authorized ATS access; do not read unrelated applicant records.
Honor retention, deletion and suppression rules across all exports.
Report the request budget and unresolved questions with the queue.

These limits should also be enforced by the application's permissions. A read-only sourcing task does not need message-send, application-update or rejection permissions.

Test the reconciliation, not a fictional hiring score

Use consented or approved fixtures to check duplicate handling, source attribution and removal propagation. Include two people with the same name, a stale employer, a missing field and a record that must not be processed.

Ask a recruiter whether the queue reduces verification work and makes uncertainty visible. Do not report a sourcing experiment as a validated hiring-quality benchmark.

For a different use of the same public job data, see hiring signals for company research. The API workflow collection keeps these task boundaries explicit: finding a company, finding a professional profile and making an employment decision are not the same operation.