Does the recruiting stack integrate: ATS, CRM, interview scheduling, and job boards?

Five separate connections sit behind that question, and each uses a different mechanism. Jobs travel outward to boards through either an XML feed the board crawls or a posting API the ATS calls [8]. Applications travel back inward, either from a form the ATS hosts or from a board posting to an endpoint your system exposes [7]. Interview scheduling reads and writes a work calendar, in practice Google Calendar or Outlook 365 [3]. Assessment, background check, and offer vendors exchange requests and results over an API, with webhooks carrying status changes back [11][13]. At hire, a subset of candidate data moves into an HRIS or onboarding platform and becomes employee data [12].

The ATS holds the system of record for hiring

Candidate data lives in the ATS as a person record with one or more application records attached, and every other system writes into that structure or reads from it. The split matters because one person can apply to several jobs, so the person and the application carry separate histories. Merge's recruiting data model uses the same shape, exposing candidates, applications, and jobs as related objects [10].

What a marketplace listing does not tell you

A logo on an integration marketplace confirms only that a connection exists. The better signal is which objects a partner may read and write, which SmartRecruiters publishes as separate Application, Assessment, Job Board, and Offer APIs [11].

Both systems store people, and that overlap causes most recruiting data problems. An ATS holds applicants, while a recruiting CRM holds people who have not applied: sourced prospects, event contacts, silver medalists, and anyone in a nurture campaign. The same human often exists in both, under two identifiers and two job titles.

Two architectures, two different problems

Where the CRM is a module of the same platform, the person record is shared and there is nothing to sync. Where the CRM is a separate product, the two systems have to agree on a match key, almost always email address. Greenhouse Recruiting flags a possible duplicate when a profile matches your organization's Duplicate tag settings, for example the same email address, phone number, LinkedIn profile URL, or name [4].

A merge is not a reversible cleanup step

Merging combines the values from both records and logs conflicts in the candidate's activity feed, which sounds harmless until you read what it does to identifiers. Greenhouse documents that manually merging profiles overwrites the candidate_id used through its API and HRIS integrations, that the secondary profile's ID stops appearing in the app and in the API, and that candidates cannot be un-merged [4]. Any system holding the old identifier then points at a record that no longer resolves, so deduplicate before ordering a background check or pushing a hire onward.

Scheduling integrations read free and busy data from a work calendar and write the interview event back, which is why Google Calendar and Outlook 365 are the connections that matter [3]. Each interviewer connects their own calendar, and that per person step is the first quiet failure point, because someone who never connected appears completely free.

Self-scheduling covers less ground than most buyers assume

Candidate self-scheduling sends a link the candidate uses to book against interviewer availability, and Greenhouse notes that self-scheduled interviews work with Google Calendar and Outlook 365 and can attach a Google Meet, Zoom, or Microsoft Teams link automatically [3]. The limit is scope: the feature applies only to stages containing one interview, such as a hiring manager screen, so panels and multi-interview loops still go through standard scheduling [3].

Panels, interviewer load, and time zones

Panel scheduling is a constraint problem rather than a calendar lookup, since the system has to find one window that satisfies several people and their limits. Ashby handles this with interviewer pools that pull people in dynamically, daily or weekly interviewer limits, multi-day scheduling for panels split across dates, and automatic generation of candidate schedules for complex loops [5].

Rescheduling is the workflow that fails most often

A reschedule is a delete plus a create executed across at least three systems: the interview record in the ATS, a calendar event on every interviewer's calendar, and the video conference link. Any system that received the create but not the delete keeps a stale event, which is how a candidate joins a call with an interviewer who believes it was cancelled. Ashby's two way event syncing reduces that exposure by updating its record when the work calendar changes [5], and testing a reschedule during evaluation matters more than testing a first booking.

Boards ingest jobs two ways, and you have to pick one. LinkedIn documents an XML feed that sends jobs when a customer creates them and a Job Posting API that posts them directly, with explicit guidance to use one or the other to avoid duplication [8]. It also separates free basic jobs, gathered from applicant tracking systems and aggregators, from paid promoted jobs posted through the API into purchased job slots [8].

Feeds refresh on the board's schedule, not yours

Indeed's Job Sync XML feed defines your jobs and how they appear, and requires elements including title, an ISO-8601 date, a unique reference number, a requisition ID, the job URL, company, location, and a description matching the career site [6]. Indeed refreshes a crawled URL or FTP feed four times a day at six hour intervals, and an Indeed hosted FTP as often as every two hours when it receives a new file [6]. A requisition can stay visible for hours after it closes in the ATS.

Hosted apply and redirect are a real trade-off

The apply flow decides both completion rate and data quality. Greenhouse offers five careers page options, from a redirect to a Greenhouse hosted board, through an iframe embed and an API driven board with the application still hosted by Greenhouse, to a fully API driven build with the form on your own site [1]. Indeed Apply sits at the other end, keeping the candidate on Indeed and posting the application to a URL you specify in the feed as JSON carrying name fields, a Base64 encoded resume, screener answers, and analytics marking it organic, sponsored, or an Indeed Targeted Ad [7]. Indeed states that jobs using its Easily apply option receive 12% more clicks [7]. Fewer steps generally produce more completed applications, while a form you host collects custom questions a board profile does not carry, so compare completions per click rather than raw counts.

These connections share one pattern: the ATS sends a request, the vendor works asynchronously for minutes or days, and a webhook carries the result back. SmartRecruiters exposes to partners an Application API, an Assessment API for requests and results, a Job Board API in XML, an Offer API, and webhooks, reached through a partner API key or an OAuth flow [11].

Background checks carry compliance weight along with the data

Checkr gives partners two ordering paths, and the difference is who touches candidate personal information. In the recommended hosted flow, the partner calls the invitations endpoint and Checkr emails the candidate to collect information and consent, creating the report once the invitation is completed [13]. In the self hosted flow, the partner collects the personal data directly and accepts more of the compliance responsibility [13]. This is not legal advice; United States background screening is governed by the Fair Credit Reporting Act plus state and local law, and software does not move that obligation off the employer.

The move into an HRIS at hire is a field mapping exercise

Hire is where recruiting data becomes employee data, and the field set is smaller than people expect. Workable exports to connected HRIS and onboarding platforms automatically when a candidate reaches the hired stage, moving photo, first and last name, personal email address, job title, start date, the resume as a PDF, LinkedIn URL, and user status [12]. Everything payroll and benefits need beyond that gets collected during onboarding. Write the field map down before go live, because a preferred name overwriting a legal name and a start date that changes after the export fired are the two failures that show up most often.

Integration failures in recruiting are rarely outages; they are quiet data problems that surface weeks later in a report nobody trusts.

Duplicate candidate records

Duplicates appear whenever two systems can create a person, and the cleanup carries consequences: a Greenhouse merge overwrites the candidate_id used by API and HRIS integrations, removes the secondary ID from the app and the API, and cannot be undone [4].

Status that never writes back

Many integrations push one direction only, so a rejection in the ATS never reaches the sourcing tool and a recruiter keeps working a candidate who is already out. LinkedIn's Recruiter System Connect closes that loop, and it shows what two way sync costs: partners must be approved by LinkedIn, sign an agreement, complete five development modules, and pass certification [9].

Scheduling collisions

Availability is only as accurate as the calendars actually connected [3], and pools with daily and weekly limits reduce collisions by making interviewer load visible to the scheduler [5].

Lost source attribution

Greenhouse attributes a candidate's source using a tracking link built from the job post URL plus a source token appended as a query parameter such as gh_src [2]. When a board rewrites the destination URL, or the candidate searches the job title and arrives another way, the application lands with no source or the wrong one, and cost per hire by channel comes from that field.

Resume parsing that disagrees between systems

The same resume can produce different fields in the board, the ATS, and a screening tool, because each runs its own parser. Indeed states that it does not send every JSON field in every request, so a receiver has to treat missing fields as empty [7].

Ask about mechanics rather than about the marketplace, because every marketplace looks complete from the outside.

• Which direction does each integration move, and what event triggers it? A connection firing only at hire behaves very differently from one syncing on every status change.
• Which objects and fields are included, and can you see the field map in writing, as Workable publishes for its hired stage export [12]?
• Who built the integration and who supports it when it fails? A partner app, a middleware connector, and your own code have different escalation paths [11][13].
• What are the API rate limits and versioning policy, and how much notice comes before an old version is retired [10]?
• How does scheduling handle a reschedule and a cancellation across every calendar and video link involved [5], and does self-scheduling cover panels or only single interview stages [3]?
• How is candidate source captured for each channel, and what happens when the tracking token is stripped [2]?
• What is the duplicate matching rule, and can a merge be reversed [4]?
• Where do integration errors appear, and does anyone get notified [13]?

One point applies to the whole category: no mandatory data standard governs recruiting integrations. HR Open Standards describes itself as the only independent, non-profit, volunteer led organization developing specifications for human resource data exchange [14], and adoption is partial, which is why unified API providers exist to normalize vendor differences [10].