Home » Blog » ATS Integration for Sourcing: Patterns, Deduplication and Attribution

ATS Integration for Sourcing: Patterns, Deduplication and Attribution

Recruiting & Talent Sourcing

ATS integration is where good sourcing quietly goes wrong. The search worked, the outreach worked, the candidate replied — and then the record lands in your applicant tracking system as a duplicate with no source tag, no outreach history and no consent flag. Six months later nobody can answer which channel produced last quarter’s hires.

The failure is rarely technical. Most integrations connect fine on day one and degrade over months as duplicates accumulate and attribution drifts. This guide covers the four connection patterns, the data-model differences that break syncs, the deduplication rules that actually work, and a checklist to run before you connect anything to your system of record.

What ATS integration is actually for

Teams usually justify an integration as a time-saving measure, and saved keystrokes are real but minor. Three other outcomes matter more.

Attribution that survives. Knowing that a hire came from outbound sourcing rather than a job board is how budget decisions get made. That tag has to be written at creation, because nobody backfills it later.
A single candidate history. Every recruiter should see that this person was approached in March, declined politely, and asked to be contacted in the autumn.
Defensible compliance records. When someone asks where their data came from, or asks to be deleted, the answer needs to live in one system rather than in five tools and an inbox.

Judge any ATS integration against those three outcomes rather than against the number of clicks it removes.

The four ATS integration patterns

Pattern	How it works	Strengths	Weaknesses
Manual export and import	CSV out of the sourcing tool, CSV into the ATS	Works everywhere, zero setup	Duplicates, no write-back, breaks attribution
Browser extension push	Recruiter pushes one profile at a time from the page	Fast, keeps a human in the loop	Inconsistent field mapping, no bulk operation
Native connector	Vendor-built two-way sync with your ATS	Deduplication, requisition tagging, activity write-back	Only available for major ATS platforms
Unified API or middleware	One integration layer normalising many ATS platforms	Broad coverage, one contract	Lowest-common-denominator fields, extra latency

Native connectors are worth paying for when they exist. The difference is not convenience: a proper connector deduplicates against existing applicants, links the record to the right requisition, writes outreach activity back, and carries consent fields. A CSV import does none of that, and every one of those omissions becomes a reporting problem later.

Check the marketplace before assuming coverage. The major platforms maintain substantial partner ecosystems — Greenhouse, Bullhorn, iCIMS and Ashby each list hundreds of integrations — but the tool you actually want may not be among them.

Why ATS data models break integrations

Most sync problems are conceptual rather than technical. Applicant tracking systems disagree about what a candidate fundamentally is, and a naive integration papers over the disagreement until it surfaces as duplicates.

Greenhouse separates the person from their applications, so one candidate can hold several applications across different jobs. Its Harvest API exposes those as distinct objects, and an integration that treats each application as a new person will manufacture duplicates immediately.

Lever models the same idea as contacts and opportunities, where an opportunity represents one pursuit of one person. The Lever API documentation sets out the distinction, and it also publishes a hard rate limit of ten requests per second per API key — a number worth knowing before you attempt to sync ten thousand sourced profiles.

Agency-oriented systems such as Bullhorn add another layer entirely, modelling clients, contacts, candidates and placements together. An integration designed for in-house ATS logic often maps poorly onto that structure, which is one more reason the agency vs in-house recruiting distinction shows up in tooling decisions.

Deduplication: the rule set that actually works

Duplicate candidate records inflate pipeline counts, corrupt source attribution, and create the situation where two recruiters screen the same person in the same week. Preventing them requires an explicit matching hierarchy rather than a vendor’s default.

Match on a stable external identifier first — a professional profile URL is the most durable option available.
Then match on personal email, which survives job changes and rarely collides.
Then match on work email, accepting that it expires whenever the candidate moves.
Then match on name plus employer as a last resort, flagged for human review rather than merged automatically.
Never merge on name alone. Common names guarantee false merges, and an incorrectly merged record is harder to repair than a duplicate.

Two operational habits reinforce the rules. Run a duplicate report monthly rather than waiting for a recruiter to notice, and decide in advance which system wins a field conflict. Usually the ATS wins on stage and status while the sourcing platform wins on contact details, because that is where each field is freshest.

Source-of-hire attribution that holds up

Attribution breaks in a predictable way. A sourced candidate is contacted in March, ignores the sequence, then applies through the careers page in June. The ATS records the source as “careers site”, the sourcing work disappears from the record, and outbound looks unproductive at budget time.

Fixing this needs three things from your ATS integration. Write the original source at record creation and never overwrite it. Store first-touch and last-touch separately, so a later application does not erase the earlier outreach. And keep an outreach activity log on the candidate record, which is the evidence that settles the argument when someone questions the attribution.

Without this, your cost per hire reporting will systematically undervalue outbound sourcing and overvalue inbound channels that merely collected the final click.

Consent, privacy fields and deletion

An integration that moves contact details without moving the surrounding context creates a compliance gap. Under GDPR you must be able to state where a record originated and when the individual was notified, and you must honour deletion requests across every system that holds the data.

Four fields should cross the integration boundary alongside the contact details: the data source, the date acquired, the lawful basis, and the date the privacy notice was served. Add a fifth if you operate a global suppression list — an opt-out flag that propagates in both directions, so a candidate who unsubscribes in your sequencing tool is suppressed in the ATS too.

Deletion deserves a specific test. Ask your vendor what happens to a record in their system when you delete it in the ATS, and confirm the answer before signing. Our guide to candidate contact data covers the wider obligations that attach to personal emails and mobile numbers.

Sync failure modes to plan for

Rate limiting. Bulk pushes hit API ceilings and fail silently in the middle. Insist on queuing with retries, and check whether partial failures are reported anywhere you will see them.
Custom field drift. Someone renames a field in the ATS and the mapping breaks without an error. Review mappings quarterly.
Stage conflicts. Two systems both believing they own candidate stage produces records that flip back and forth. Designate one owner per field.
Bulk import contamination. A one-off import of 5,000 unverified profiles floods the ATS with records that will never convert and permanently distorts your funnel ratios.
Credential expiry. OAuth tokens lapse, and the sync stops without announcing itself. Monitor sync volume, not just sync status.

That last one causes more damage than it should. A silent integration failure looks identical to a quiet hiring week until someone checks the numbers a month later.

The pre-connection checklist

Run this before connecting any sourcing tool to your system of record. Every question has a right answer, and vendors that cannot answer them are telling you something useful.

Is the sync one-way or two-way, and which fields move in each direction?
What is the deduplication logic, and can we configure the matching hierarchy?
Does the integration write source, first touch and last touch as separate fields?
Is outreach activity written back to the candidate record, or only stored in the sourcing tool?
How are consent, lawful basis and opt-out status carried across?
What happens on rate limiting, and where are partial failures reported?
Can records be pushed to a specific requisition, or only to a general pool?
What happens to data in the vendor’s system when we delete a record or end the contract?

Test with fifty records before committing to five thousand. Duplicates created at small scale are an afternoon’s cleanup; duplicates created at large scale are a quarter’s project. Our vendor buying checklist covers the commercial questions that pair with these technical ones.

Frequently asked questions about ATS integration

Should sourced candidates go into the ATS immediately?

Only once they have engaged. Pushing every sourced profile into the ATS floods it with records that never convert and destroys your funnel ratios. Keep untouched prospects in the sourcing platform and push on first meaningful reply.

Is a unified API good enough, or do we need a native connector?

A unified API is fine for standard fields and broad coverage. Native connectors handle the awkward parts — custom fields, requisition tagging, activity write-back — which is exactly where reporting quality lives. If a native connector exists for your ATS, prefer it.

How do we clean up existing duplicates?

Export, match on profile URL and personal email, and review anything matched only on name before merging. Fix the creation rules first, because cleaning duplicates while the source of them still runs simply recreates the work.

Who should own the integration internally?

A named person in recruiting operations rather than IT. The failures are semantic — field meaning, attribution rules, stage ownership — and they need someone who understands the hiring process rather than only the API.

Does an integration help time to fill?

Indirectly, and mostly through fewer handoffs and faster replies. The larger benefit is measurement: without clean attribution you cannot tell which channel shortens time to fill, so you cannot deliberately invest in it.

Connect deliberately, review quarterly

A good ATS integration is not the one with the most fields mapped. It is the one where a candidate exists once, carries an accurate source, shows every previous touch, and can be deleted completely on request.

Set the deduplication rules deliberately, protect the attribution fields, and review the mappings every quarter before drift turns into a data project.