HR Open Schemas: Stop Candidate Data Breakage in Integrations
A practical integration playbook to make candidate data portable across your ATS, verification, interviews, and assessments without turning every tool swap into a revenue-risk project.
If candidate identity and evidence are not portable, every tool change becomes a revenue-risk event.Back to all posts
A tool swap turns into a hiring stoppage
Your ATS migration is in week two when the VP of Sales escalates: three enterprise deals are waiting on solutions engineers, and the hiring funnel is "stuck." The real issue is mundane and brutal: candidate identities are duplicated across tools, verification outcomes are not reliably attached to the right application, and recruiters are rerunning checks to compensate. By the end of this article, you will be able to standardize candidate data with HR Open schemas so candidate identity, stage, and evidence stay portable across tools with fewer integration fire drills.
Schema drift is revenue risk, not an IT nuisance
Recommendation: treat candidate data portability as a control that protects cycle time and reputation. If your stack cannot move a verified identity and its Evidence Pack cleanly between systems, you create funnel leakage, reviewer fatigue, and audit exposure exactly when headcount pressure is highest. Checkr reports that 31% of hiring managers say they've interviewed a candidate who later turned out to be using a false identity. Directionally, this suggests identity integrity failures are common enough to hit mainstream hiring. It does not prove your org has the same rate, and a manager survey is not the same as an incident log measured in your environment.
Speed: recruiters wait on manual reconciliation or rerun steps.
Cost: extra vendor usage and wasted interviewer time.
Risk: disputed decisions without a consistent chain of custody.
Reputation: candidates get asked for the same data multiple times.
Key terms you will use in the rollout
These terms prevent cross-functional misalignment during implementation and are useful in policy and audit language.
Use a canonical schema so every integration maps to the same contract.
Use Evidence Packs so decisions are backed by reviewable artifacts, not screenshots.
Use idempotent delivery so retries do not create duplicates.
Ownership and flow so schema work does not stall
Recommendation: assign explicit ownership by object type and keep the ATS as the stage authority, not the evidence vault. This avoids the common failure mode where nobody can confidently answer "which system is right" during an escalation.
Recruiting Ops: canonical field map, stage vocabulary, integration change-control.
Security: verification policy, access controls, retention and appeal workflow.
Hiring managers: rubric outcomes and hiring decisions, not identity adjudication.
Automate: object creation and updates, risk-tier assignment, Evidence Pack linking, webhook retries.
Manual review: only flagged cases, candidate appeals, and false-positive adjudication.
ATS: requisitions, application stage, offer state.
Verification: identity outcome, liveness, document checks, risk tier, Evidence Packs.
Interviews and assessments: timestamps, artifacts, scores, integrity signals.
How to standardize on HR Open without boiling the ocean
Recommendation: implement HR Open as your canonical schema, then map each tool to it. Avoid tool-to-tool point mappings that multiply every time you add a vendor.
Candidate: legal name, preferred name, emails, phones, location, consent, createdAt.
Application: requisitionId, stage, source, timestamps.
Verification: verificationSessionId, status, riskTier, verifiedAt, evidencePackId.
Linking: candidateId must be stable across the entire lifecycle.
candidateId: UUID minted once and never changed.
verificationSessionId: per verification attempt, supports reruns without ambiguity.
Dedupe keys: email and phone are helpers, not primary keys.
Use a controlled vocabulary aligned to: Source candidates -> Verify identity -> Run interviews -> Assess -> Offer.
Disallow free-text stages and per-team naming variants.
Store outcomes and pointers to Evidence Packs, not raw artifacts inside the ATS.
Default to Zero-Retention Biometrics and least-privilege access for evidence.
Deploy with canaries, kill switches, and replay
Recommendation: ship schema standardization as an integration capability with rollback. Your funnel cannot depend on a perfect mapping on day one.
Build a mapping table plus fixtures for edge cases (name changes, duplicates, reapplications).
Implement idempotent webhooks with dedupe keys and a replay endpoint.
Add a canary selector (by requisitionId or recruiting team) to limit blast radius.
Add an ATS writeback kill switch when mapping errors spike.
Queue events when the ATS is down, then reconcile by traceId when it recovers.
Alert on orphaned verification sessions (no applicationId link).
Monitor duplicate candidateId creation and stage vocabulary violations.
Run a weekly drift report: unmapped fields and unexpected null rates.
A mapping policy you can actually run
Use this as the control document that Recruiting Ops, Security, and Legal can approve. It encodes the canonical schema, mappings to common ATS fields, idempotent delivery rules, and rollout controls.
Anti-patterns that make fraud worse
- Letting each tool mint its own "candidate ID" and relying on email to reconcile later. - Stuffing raw verification artifacts into the ATS instead of linking an access-controlled Evidence Pack. - Allowing stage names to vary by team or recruiter, which makes controls inconsistent and audits painful.
Where IntegrityLens fits
IntegrityLens AI is the first hiring pipeline that combines a full Applicant Tracking System with advanced biometric identity verification, AI screening interviews, fraud detection, and technical assessments in one defensible workflow. In a schema-standardized stack, IntegrityLens can act as the execution layer (ATS plus assessments) and the integrity layer (Risk-Tiered Verification plus Evidence Packs) that stays consistent even when other tools change. TA leaders and recruiting ops teams use it to keep throughput high; CISOs use it to validate controls and retention; RevOps gets predictable hiring velocity without integration surprises.
ATS workflow end-to-end
Identity verification before interviews (typical 2-3 minutes end-to-end)
24/7 AI screening interviews
Coding assessments across 40+ languages
Audit-ready Evidence Packs with privacy-first handling
Metrics that tell RevOps if portability is working
Recommendation: measure a small set of integrity and throughput indicators tied to schema correctness, not vanity dashboards. When these move, you will feel it in time-to-offer and incident volume.
Orphan rate: verification sessions without an application link.
Duplicate rate: multiple candidateIds for the same person after dedupe.
Manual rework: count of rerun verifications or assessments due to mismatch.
Time-to-identity-gated: elapsed time from apply to verified state.
Dispute cycle time: time to produce an Evidence Pack for Legal or Security.
Related Resources
Key takeaways
- Treat HR Open as the canonical contract between tools, not a nice-to-have export format.
- Make the ATS the system of record for requisition and stage, but not for verification evidence and risk decisions.
- Use stable, cross-tool identifiers (candidateId + verificationSessionId) to stop duplicate profiles and orphaned evidence.
- Ship integrations with canary rollout and a kill switch so a bad mapping does not stall the funnel.
- Log immutable events and attach Evidence Packs so disputes are resolved with data, not opinions.
A runnable control document for standardizing candidate data across ATS, verification, interviews, and assessments.
Includes stable identifiers, stage vocabulary, idempotent webhooks, canary rollout, and a kill switch for ATS writeback.
policy:
name: hr-open-canonical-candidate-v1
version: 1.3.0
owner:
primary: recruiting-ops
approvers: [security, legal]
canonicalSchema:
standard: hr-open
objects:
candidate:
requiredFields: [candidateId, legalName, emails, consent, createdAt]
application:
requiredFields: [applicationId, candidateId, requisitionId, stage, appliedAt]
verification:
requiredFields: [verificationSessionId, candidateId, status, riskTier, evidencePackId, verifiedAt]
identifiers:
candidateId:
strategy: uuid
immutability: true
dedupeKeys:
- type: email
normalization: lowercase-trim
- type: phone
normalization: e164
- type: governmentIdFingerprint
storage: hash-only
fieldMappings:
greenhouse:
candidate.id: candidate.candidateId
candidate.first_name: candidate.legalName.given
candidate.last_name: candidate.legalName.family
candidate.email_addresses[]: candidate.emails[]
application.id: application.applicationId
application.job_id: application.requisitionId
application.stage: application.stage
lever:
candidate.id: candidate.candidateId
candidate.name: candidate.legalName.full
candidate.emails[]: candidate.emails[]
opportunity.id: application.applicationId
opportunity.requisition_id: application.requisitionId
opportunity.stage: application.stage
integritylens:
personId: candidate.candidateId
sessionId: verification.verificationSessionId
outcome.status: verification.status
outcome.risk_tier: verification.riskTier
evidence.pack_id: verification.evidencePackId
stageVocabulary:
allowed:
- sourced
- identity-gated
- interview
- assessment
- offer
- hired
- rejected
transitions:
identity-gated:
requires: [verification.status]
rollout:
mode: canary
canarySelector:
type: requisitionId
allowList: ["REQ-1042", "REQ-1071"]
killSwitch:
enabled: true
trigger:
metric: mapping_error_rate
threshold: "2%" # illustrative example, set from your baseline
windowMinutes: 15
action: disable_ats_writeback
webhooks:
idempotency:
key: "${source}:${eventId}"
ttlHours: 72
retry:
maxAttempts: 12
backoff: exponential
privacy:
biometrics:
mode: zero-retention
storeRaw: false
accessControls:
leastPrivilege: true
evidencePackReadRoles: [security, recruiting-ops]
encryption:
atRest: aes-256
inTransit: tls-1-2-plus
Outcome proof: What changes
Before
Candidate identities were duplicated across systems, verification outcomes were sometimes attached to the wrong application, and Recruiting Ops had to manually reconcile records during executive escalations.
After
A canonical HR Open schema and stable identifiers made candidate records portable across tools, with idempotent webhooks and replay preventing duplicates. Evidence Packs were linked consistently, improving dispute handling without slowing the funnel.
Implementation checklist
- Pick a canonical schema (HR Open) and freeze a version for 90 days.
- Define system-of-record per object: Candidate, Application, Interview, Assessment, Verification.
- Create a field mapping table and a test fixture set with edge cases (name changes, multiple emails, reapplications).
- Implement idempotent webhooks with replay and dedupe keys.
- Add an integration kill switch and canary rollout by requisition or team.
- Instrument trace IDs so you can follow one candidate through every tool.
Questions we hear from teams
- What is identity gating in a hiring pipeline?
- Identity gating is a control where a candidate must reach a defined verification state (for example, verified or needs-review) before advancing to higher-trust stages like live interviews or offers.
- Do we need HR Open to integrate tools successfully?
- You can integrate without it, but HR Open reduces long-term integration churn by giving you a stable contract. Without a canonical schema, every vendor swap becomes a bespoke migration with higher odds of orphaned evidence and duplicated candidates.
- What happens when the ATS is down during verification?
- Queue events in your integration layer, keep idempotency keys, and reconcile when the ATS recovers using traceId and candidateId. Do not drop verification outcomes or retry blindly in a way that creates duplicates.
Ready to secure your hiring pipeline?
Let IntegrityLens help you verify identity, stop proxy interviews, and standardize screening from first touch to final offer.
Watch IntegrityLens in action
See how IntegrityLens verifies identity, detects proxy interviewing, and standardizes screening with AI interviews and coding assessments.
