ATS integration for outreach automation sounds more complicated than it needs to be. When teams first come to us, many assume connecting Bling Cloud to their ATS will be a months-long IT project. In most cases, it is not. But you do need to understand which data the outreach and screening layer actually needs, versus which data your ATS owns and should keep owning, versus which data is genuinely not relevant to the automation workflow at all. This article covers that distinction for the three ATS platforms we encounter most: Greenhouse, Lever, and Workday Recruiting.
We are not covering every ATS edge case here. If you are on iCIMS, Taleo, or a custom-built internal system, the principles apply but the mechanics differ enough to warrant a separate conversation.
The integration model: what needs to flow and in which direction
ATS integration for bulk hiring outreach is fundamentally a one-and-a-half-way data relationship. You pull candidate contact information and role details from the ATS into the outreach system. You push disposition updates back when a candidate is screened and qualified or disqualified. You do not need to push calendar events back into the ATS in the initial setup, though some teams want that eventually. Call recordings and transcripts are typically stored in the outreach system, not written back to the ATS record, unless your compliance team has a specific requirement for candidate record retention in the ATS.
The reason the direction matters is that both Greenhouse and Lever have webhook systems that can push candidate stage changes out in near-real-time. That is the cleanest integration path for incoming candidate data: your ATS pushes new applicants at a configured stage trigger, your outreach system receives them and queues them for calls. The alternative, polling the ATS API on a schedule, works but adds latency and creates a more fragile connection that requires monitoring.
What data you actually need from the ATS
At minimum, you need five fields per candidate to run outreach and screening: first name, a phone number, the job title they applied to, the location of the role (city and site, not just a job ID), and their application stage at the time of handoff. That is it. Everything else is optional and often creates noise rather than utility in the automation layer.
Resume content is a good example of optional data that teams often assume they need. For hourly roles where first-pass qualification is based on availability, physical requirements, and prior work experience, the resume is less useful than a direct conversation. The AI call will elicit the availability and experience information directly. Parsing resume text to pre-fill qualification assumptions tends to introduce errors, particularly for candidates who have informal work history or non-standard resume formats, which is common in hourly applicant pools.
Custom ATS field data, like sourcing channel or requisition status codes, is generally not useful to pass into the outreach layer. It adds integration surface area without changing the outreach logic. The one exception is urgency flags or priority codes some teams use on specific requisitions. If your Greenhouse setup uses a custom field to mark high-priority roles, it is worth surfacing that in the integration so the outreach queue can deprioritize calls accordingly.
Greenhouse: webhook setup and API scope
Greenhouse uses a webhook system called "Web Hooks" (under Configure in the admin panel). For outreach automation, you want to trigger on the "Candidate Changed Stage" event, filtered to whichever stage you want to use as the handoff point. Most teams use an "AI Screen" or "Phone Screen" stage they create specifically for this purpose, positioned before their human recruiter screen stage.
API scope for Greenhouse should be read access to candidates and jobs, plus write access to candidate activity (for pushing back screen results and notes) and stage advancement (if you want the system to automatically move qualified candidates to the next stage). You do not need write access to job creation or team management endpoints. Greenhouse's Harvest API documentation is reasonably clear on scope granularity. We recommend creating a dedicated API key for the integration rather than using a personal token, so access can be revoked cleanly if needed.
One Greenhouse-specific issue: custom job fields do not always appear on the standard job endpoint response. If your team uses custom fields to store role-specific screening criteria (shift type, physical requirements, license requirements), you may need to call the custom fields endpoint separately and merge that data in. This is a common surprise during setup and adds about half a day of integration work.
Lever: the data model difference
Lever's data model treats the "Opportunity" as the primary object rather than the candidate. This matters because when a candidate applies to multiple roles, each application is a separate opportunity record with its own stage history. For bulk hiring where candidates sometimes apply to multiple locations simultaneously, your integration logic needs to handle deduplication at the opportunity level, not the candidate level.
Lever uses a webhook system similar to Greenhouse. The relevant event is "stageChange" on the Opportunity object. Lever's API authentication uses OAuth2, which adds a token-refresh step that a polling integration needs to handle explicitly. The webhook approach sidesteps this but requires configuring a receiving endpoint on your outreach system that can handle Lever's signed webhook payloads.
Lever's API response bodies are larger than Greenhouse's by default, because they include the full opportunity history rather than just current state. For bulk pipelines where you are processing hundreds of new candidates per day, this is worth noting for throughput planning. In practice it has not been a bottleneck for teams in our pilot range, but it is something to keep in mind if you are on Lever and running very high daily ingest volumes.
Workday Recruiting: the harder path
Workday Recruiting is the most complex of the three. Workday does not expose a simple webhook event system for candidate stage changes. The standard integration path is through Workday's SOAP-based web services (called "Human Resources" or "Staffing" service groups), which require a certified integration developer to configure correctly. Workday also uses a concept called "Integration System Users" that must be provisioned by your Workday admin before any external API access is possible.
For teams on Workday who are not ready to engage their IT or implementation partner on a SOAP integration, there is a practical alternative: a scheduled CSV export from Workday Recruiting to an SFTP location that the outreach system picks up on a defined cadence. This is not real-time and adds lag of whatever interval you set, typically 15 to 60 minutes, but it works reliably and does not require IT project scope. Most high-volume hourly hiring operations can tolerate 30-minute candidate handoff latency without meaningful pipeline impact.
We are not going to pretend the CSV path is as good as the webhook path. It is a practical tradeoff for teams where the proper integration is gated behind organizational capacity that does not move at recruiting speed. You know your team's situation. We have supported both.
What you do not need to build
Several integration features come up in early conversations that turn out to be unnecessary for the core workflow. Two-way calendar sync between the ATS and the interview booking calendar is one. Bling Cloud writes confirmed interview slots to the recruiting team's calendar directly (Google Calendar or Outlook). Pushing those events back into the ATS as activity notes is a cosmetic step that some teams want for record-keeping, but it is not required for the operational loop to function. You can add it later once the core outreach and screening workflow is stable.
Resume parsing and enrichment from the ATS record is another. We covered this above: for hourly roles, the direct call elicits more accurate information than resume text for the criteria that matter in first-pass qualification. Do not spend integration budget on resume data flow if your qualification logic does not actually need it.
Stage rollback triggers, where a disqualified candidate's stage in the ATS gets rolled back automatically, create more problems than they solve. Leave stage management in the hands of your recruiters for disqualified candidates. Automated rollbacks conflict with how most teams want to handle candidate records and can cause confusion when a recruiter is reviewing pipeline state.
The cleanest ATS integration for bulk hiring outreach is the narrowest one that covers the data handoff points you actually need. More integration surface area means more maintenance work when either system updates its API, and for a recruiting operations team that does not have a dedicated integration engineer, that maintenance cost is real.