For recruitment process outsourcing providers
One screening method across every client program
Each client brings its own ATS, its own rules and its own retention policy. Put HireLayer behind your integration layer to parse applications, structure requisitions and document screening the same way for all of them, with each client’s references carried through.
The problem
What makes RPO delivery hard to standardize
You sell a consistent process. Your clients’ systems, contracts and hiring managers pull in the opposite direction.
- 01
Every client runs a different stack
Recruiters work in several ATSs in the same week, each structuring candidates differently, or not at all.
- 02
Screening varies by recruiter
The same requisition type is screened differently from one program to the next, and it shows in client reviews.
- 03
Retention rules differ per contract
One client allows candidate data to be retained by sub-processors, another forbids it.
- 04
Every result must trace back
Audits and disputes require linking a screening outcome to the client’s own application record.
Program configuration
Same endpoints, client-specific rules
Per-client settings live in your integration layer and reach HireLayer as request fields. A sketch of how three programs could differ.
How it fits
Inside your integration layer
Client ATSs connect to your delivery platform. Your platform calls HireLayer with each client’s settings and writes results back.
- Your system
Step 1, your system: An application lands in a client ATS
Your integration picks it up through the client’s API or webhook.
- HireLayer
Step 2, HireLayer API: Parse with the client’s reference
application_id carries the client and application reference; do_not_store_data follows the client’s contract.
POST /
api/ v3/ parser - request_id
- info_resume.application_id
- HireLayer
Step 3, HireLayer API: Structure the requisition once
At kickoff, extract criteria and have the hiring manager sign them off.
POST /
api/ v1/ jobs/ extract-criteria - matching_criteria[]
- HireLayer
Step 4, HireLayer API: Screen each applicant
Evaluate against the validated criteria and keep statuses and explanations as the screening note.
POST /
api/ v1/ matching/ job-candidate - score
- evaluated_criteria[]
- Your system
Step 5, your system: Write back to the client ATS
Push structured fields and the screening note to the client record, with request_id kept for audit.
Planning a multi-program rollout? We can walk through volumes and Enterprise terms.
Book a callTechnical example
Parse with a client reference and no retention
The same call for every program; only the reference and the retention flag change with the client’s configuration.
- application_id
- Any string: encode client, requisition and application.
- do_not_store_data
- Set per request from the client’s contract.
- request_id
- Keep it with the write-back for audit and support.
curl -X POST https://onlineresumeparser.com/api/v3/parser \
-H "X-API-Key: YOUR_API_KEY" \
-F "file=@application_88412.pdf" \
-F "application_id=acme-retail:REQ-2291:APP-88412" \
-F "do_not_store_data=true"{
"status": "success",
"request_id": "fe075a87-0a55-4534-babb-37141c2bcbc2",
"info_resume": {
"application_id": "acme-retail:REQ-2291:APP-88412",
"language": "EN",
"text": "…"
},
"info_candidate": {
"full_name": "Jordan Ellis",
"job_title": "Payroll Specialist",
"experience_level": "5 to 10 years"
}
}Outcomes
What your delivery organization gains
A shared screening standard
Every program uses the same criteria format and the same status scale.
Contract-aware processing
Retention is set per request, so one integration serves clients with different policies.
Traceable results
application_id and request_id link each output to the client record and to the API call.
Recruiters stay accountable
Statuses inform the screen; decisions and client communication stay with your team.
APIs used
The HireLayer APIs behind this workflow
Start with the core APIs, add the others when a feature needs them. All five share one API key and one credit balance.
- HireLayer CV Extract
Resume Parsing API
Core to this workflowDocs for HireLayer CV ExtractParses each application with the client’s reference and retention setting.
- HireLayer Job Extract
Job Parsing API
Core to this workflowDocs for HireLayer Job ExtractTurns each requisition into criteria the hiring manager signs off.
- HireLayer Match
Candidate & Job Matching API
Core to this workflowDocs for HireLayer MatchProduces a structured screening note for each applicant.
- HireLayer Rank
Candidate Ranking API
Add when neededDocs for HireLayer RankOrders a requisition’s slate before the client review.
- HireLayer Skills
Skills Matching API
Add when neededDocs for HireLayer SkillsMaps skills to one catalog for talent reporting across programs.
FAQ
RPO providers: frequently asked questions
Do you integrate directly with our clients’ ATSs?
No. HireLayer has no ATS connectors. Your integration layer, which already talks to each client ATS, calls the API and writes results back.
How do we keep each client’s data separate?
Encode the client in application_id, store results in each client’s space in your platform, and set do_not_store_data for clients whose contract forbids retention by sub-processors.
Can hiring managers edit the criteria?
Yes. Extracted criteria are plain JSON. Hiring managers can change weights, flags or labels, and Match accepts the edited list as long as each criterion keeps the same five fields.
How is usage billed across programs?
All calls draw from one credit balance, one credit per successful call. Log request_id per program to allocate usage. The Enterprise plan covers custom volumes and integration needs.
Can screening run on a callback instead of waiting?
Parsing V3 is synchronous and also accepts a webhook_url for a callback. Your integration can use either pattern.
Pilot it on one program
Start with one requisition type in one client program, then extend program by program. The free plan includes 50 credits a month, shared by all five APIs.
