Background screening integration
A direct API connection between a background check vendor and an ATS that lets recruiters initiate consent requests, track check status, and receive structured results inside the candidate record without switching systems.
Michal Juhas · Last reviewed May 15, 2026
What is background screening integration?
A background screening integration connects an ATS directly to a background check vendor through an API so recruiters can initiate a check, track its progress, and receive structured results inside the candidate record without logging into a separate portal or re-entering data.
The integration handles the sequence: the ATS triggers a check request when a candidate reaches the configured stage, the vendor sends a digital consent form to the candidate, and once consent is confirmed, the vendor runs the check and posts the result back as a webhook. The ATS updates the candidate stage based on the outcome, and a named reviewer decides what happens next.
The key governance point is that the integration automates data movement, not decisions. FCRA adverse action, GDPR deletion rights, and ban-the-box timing rules all require human judgment at defined moments in the process.
In practice
- When a recruiter advances a candidate to "background check" in Greenhouse or Lever and the candidate immediately receives an email from Checkr or Sterling asking them to complete an authorization form, that is a background screening integration firing. The recruiter never left the ATS.
- A TA ops lead who says "the check is stuck in pending" is usually describing a silent integration failure: the webhook fired but the candidate never received the consent form, so the check never started.
- Most vendor sales decks show the integration as a one-click flow. Practitioners running live pipelines know the real work is configuring the trigger stage, setting up the field mapping, and building the monitoring step that catches failed deliveries before they delay a start date.
Quick read, then how hiring teams use it
This is for recruiters, TA leaders, and HR partners who need the same vocabulary in vendor evaluations, compliance audits, and process design. Skim the first section for a fast shared picture. Use the second when you are configuring the integration, reviewing your DPA, or dealing with a candidate data request.
Plain-language summary
- What it means for you: Instead of emailing a candidate a separate form, logging into the background check portal to order the check, and checking back to copy results into the ATS manually, the ATS and the vendor talk directly. You initiate, track, and receive results in one place.
- How you would use it: You configure which ATS stage fires the check, which check package applies to which role type, and who gets notified when a result needs review. After that, the integration runs for every new candidate who reaches that stage without additional manual steps.
- How to get started: Map your current hiring process to identify the exact stage where the check should fire. Read the vendor's integration guide and your ATS connector documentation before configuring anything. Test with a dummy candidate and verify that the consent form lands, the result writes back to the ATS field, and the monitoring alert fires correctly.
- When it is a good time: After your hiring process is stable, after your compliance team has reviewed the trigger stage and the consent language, and after you have a named owner for the daily check-status monitoring step.
When you are running live reqs and tools
- What it means for you: Every automated trigger is also an automated compliance event. The integration creates a timestamped record of when the check was initiated, who the candidate was, and what consent was captured, which is exactly what FCRA and GDPR auditors ask for. That audit trail is an asset when configured correctly and a liability when the consent step was skipped or the field mapping was wrong.
- When it is a good time: After the trigger stage is aligned with your offer process, the consent language is reviewed by legal, and the adverse action workflow has a named human owner. Not before.
- How to use it: Wire the ATS trigger to the conditional offer acceptance event, not a loose stage click. Configure the vendor package by role type so the right check runs without a recruiter choosing from a dropdown each time. Set up a dead-letter alert for any check that has not progressed from consent pending after 48 hours. Cross-link to workflow automation documentation so the ATS stage change and the check trigger are in the same runbook.
- How to get started: Pull your last quarter's background check volume and identify how many resulted in adverse action. If none ever did, check whether the review step actually happened or whether all results were cleared automatically. Review your vendor's DPA and confirm it covers every jurisdiction you hire in. Ask your ATS admin to export a log of check triggers for the last 30 days and verify the trigger stage is correct for every record.
- What to watch for: Consent links that expire before the candidate completes authorization, duplicate checks from re-triggering a stage, result fields that write to the wrong ATS column, and adverse action notices sent without a pre-adverse waiting period. The human-in-the-loop principle applies directly: the integration moves data, but every decision to advance or reject based on a result must pass through a documented human review step.
Where we talk about this
On AI with Michal live sessions, background screening integrations come up in the AI in recruiting and sourcing automation tracks when we work through the full offer-to-start sequence. The compliance layer, specifically what the ATS can automate versus what must stay with a named human, is a recurring design question. If you want the room conversation with other TA practitioners building or auditing their screening pipelines, start at Workshops and bring your current ATS configuration and your vendor DPA.
Around the web (opinions and rabbit holes)
Third-party creators move fast. Treat these as starting points, not endorsements, and double-check anything before you wire candidate data to a new vendor.
YouTube
- FCRA Compliance for Employers: What You Need to Know covers the disclosure, authorization, and adverse action steps that every background check process must include, useful before you configure any integration.
- Background Check Integrations with Your ATS walks through a vendor-agnostic view of how background check APIs connect to applicant tracking systems and what can go wrong.
- HR Tech Integration Deep Dive: Background Screening discusses field mapping, webhook reliability, and the compliance checkpoints that TA ops teams typically discover too late.
- Anyone use Checkr with Greenhouse? in r/recruiting has honest practitioner notes on integration reliability, consent form completion rates, and what breaks in practice.
- Background check integration horror stories? in r/humanresources is a useful thread for understanding failure modes before you go live.
- FCRA adverse action process - is anyone actually following this correctly? in r/humanresources is a frank discussion of how the adverse action workflow breaks down in practice.
Quora
- How do background check integrations work with ATS platforms? collects vendor and practitioner perspectives on the technical and compliance layers of connecting ATS and screening tools.
Integration versus manual background check process
| Dimension | Integration | Manual process |
|---|---|---|
| Consent capture | Digital form sent automatically at trigger | Recruiter emails a separate form and tracks replies |
| Audit trail | Timestamped in ATS event log | Depends on recruiter documentation habits |
| Duplicate check risk | Requires de-dupe configuration | Caught manually if at all |
| FCRA adverse action | Still requires human review step | Also requires human review step |
| Field mapping errors | Surfaced in integration logs | Silent until a candidate record is wrong |
| Data retention compliance | Configurable in vendor settings | Relies on recruiter deleting files manually |
Related on this site
- Glossary: ATS API integration, Applicant tracking system, Recruiting webhooks, Workflow automation, Human-in-the-loop (HITL), Candidate data enrichment, Adverse impact
- Blog: AI sourcing tools for recruiters
- Guides: Sourcers
- Live cohort: Workshops
- Self-paced: Starting with AI: the foundations in recruiting
- Membership: Become a member
Frequently asked questions
What triggers a background check through an ATS integration?
Most integrations fire when a recruiter advances a candidate to a configured ATS stage (typically offer extended or pre-boarding) and the ATS sends a webhook to the background check vendor with the candidate name, email, and a consent flag. The check does not start until the vendor confirms consent was captured, either through a digital authorization form the candidate completes or a consent assertion the recruiter marks as collected. Configuring the trigger stage carefully matters: too early and you run checks on candidates who have not received an offer; too late and you delay start dates. Most TA ops teams anchor the trigger to a conditional offer acceptance event rather than a loose stage click, which makes the trigger auditable and aligns with FCRA timing rules.
What compliance obligations attach to a background screening integration?
In the United States, the Fair Credit Reporting Act requires a standalone written disclosure and a separate candidate authorization before a consumer report can be ordered. An integration that fires automatically without capturing this consent is a federal compliance violation regardless of how streamlined the ATS workflow looks. Internationally, GDPR requires a lawful basis for processing personal data with a third-party vendor, a data processing agreement with the screening provider, and documented candidate rights to access, correction, and deletion. Ban the Box laws in many US states and cities add timing restrictions on when criminal history can be collected relative to the hiring stage. Your background check vendor should supply a DPA and a jurisdiction-by-jurisdiction compliance checklist before go-live.
How does the adverse action process work when a check returns a flag?
FCRA requires a two-step process before withdrawing an offer based on a background check result. You send a pre-adverse action notice with a copy of the report and a summary of the candidate's rights, then wait a reasonable period (typically five business days) before sending a final adverse action notice. The integration cannot automate this decision: a named reviewer must assess whether the specific finding is job-relevant and document the conclusion before the ATS record is updated to rejected. Most integrations surface a review-required status when a result is not clear, but the human decision step must precede any stage advance or rejection. Log who reviewed, what criteria applied, and when the decision was made. Skipping this step is the most common FCRA failure TA teams encounter when first deploying a workflow automation for screening.
What are the most common failure modes in background check integrations?
Silent partial triggers are the most disruptive: the ATS fires the webhook, the vendor acknowledges receipt, but the check never reaches the candidate because an email bounced, the consent link expired, or a special character broke the JSON payload. Teams typically discover this only when a hiring manager asks why screening is still pending two weeks later. Other failure modes include duplicate checks triggered when a recruiter re-advances a stage, result fields that do not map correctly to the ATS candidate record, and status recruiting webhooks failures that leave a record showing in-progress after completion. Assign one person to review any check open longer than five business days, configure vendor alerts for failed deliveries and expired consent windows, and test the full integration with a dummy candidate before the first live req.
What data should the ATS pass to the vendor in the initial request?
The minimum safe set is the candidate's full legal name as entered on the application, email address for the consent form, the position type to set the appropriate package, and the intended start state or country to apply the correct legal rules. Do not pass more than the vendor needs to initiate a check. Social Security numbers, date of birth, and address history should be collected by the vendor directly from the candidate through the consent form rather than prepopulated by the ATS, because once those fields land in your ATS event log they become PII your IT and security teams must govern. Confirm with your vendor which fields are required, which are optional, and which the candidate must supply directly, then configure the ATS API integration field mapping to match.
When should the integration fire relative to the hiring stage?
The integration should fire at the last reasonable point before an irreversible commitment, typically after a verbal offer acceptance and before a written offer letter, or after a conditional offer letter where the offer is explicitly contingent on a satisfactory check. Teams that trigger the integration too early, at phone screen or first interview, waste check fees on candidates who do not advance, create unnecessary data processing obligations, and in some jurisdictions violate ban-the-box timing rules prohibiting criminal history inquiry before a conditional offer. Map ATS stages to the trigger point, document the trigger criteria in your hiring process guide, and confirm the logic with your legal or HR compliance team before go-live. Review the configuration quarterly, because ATS stage names often change when a process is redesigned.
How do you handle candidate data after the background check is complete?
Background check reports contain sensitive personal data including financial history, criminal records, and identity verification details, and most jurisdictions impose retention limits. Agree on a retention period with your vendor before go-live, typically six months to two years depending on the jurisdiction and hire outcome. For hired candidates, check whether your HR system needs the full report or only the pass/fail result: storing full reports in the ATS beyond the retention window creates compliance exposure. GDPR and CCPA both give candidates the right to request deletion. Configure the integration to honor deletion requests so that a right-to-erasure request to your HR team flows through to the vendor record automatically. Document the data flow in your privacy notice and your data processing agreement with the vendor. See candidate data enrichment for the broader data governance pattern.
