To connect your ATS for automated candidate screening, you need three things: an ATS with a reliable API, a Make.com account, and a clear map of where candidates go after they apply. With those in place, you can route, filter, and notify on every applicant without touching a keyboard — and your team focuses on the people, not the pipeline.

Key Takeaways

• ATS integration with Make.com requires API credentials, a webhook or polling trigger, and a defined screening logic before you build anything.
• Automated screening reduces time-to-first-contact from days to minutes without adding headcount.
• The most common failure point is skipping the validation step — builds that look right in testing break silently in production.
• A two-step architecture (filter first, notify second) keeps the system clean and auditable.
• Over-automating the rejection step is the fastest way to damage candidate experience and employer brand.

Most HR teams know their ATS is underused. Applications come in, get reviewed manually, and move forward (or don’t) based on whoever had bandwidth that day. That’s not a people problem — it’s a system design problem. The fix starts with connecting your ATS to an automation layer that handles the routing, filtering, and communication steps the system was never built to do alone. If you’re still paying for HR tools that aren’t talking to each other, the HR SaaS Pricing Mistakes — Complete 2026 Guide covers exactly why disconnected stacks cost more than the licenses themselves.

This guide walks through the complete setup: prerequisites, the step-by-step build in Make.com, how to validate it works, and the mistakes that derail most teams before they get there.

Before You Start

Jumping straight into the build without these prerequisites in place wastes time and creates rework.

What you need before building

1. ATS with API access enabled
Not all ATS plans include API access. Check your current subscription — some vendors gate it behind higher tiers or require a formal API request. Common ATS platforms with solid API documentation: Greenhouse, Lever, Workable, BambooHR (for HRIS-side), and JazzHR. Confirm you have read and write permissions, not just read.

2. Make.com account (paid tier recommended)
Free Make.com accounts run scenarios manually or on limited intervals. For candidate screening to work in real time, you need a paid plan that supports webhooks and scheduled triggers at intervals under 15 minutes. Make.com is the automation platform this guide is built around — no substitute produces the same results with the same traceability.

3. A screening criteria document
Before you automate anything, write down exactly what “qualified” means. Which job fields are required? What disqualifies an applicant immediately? What sends them to a human? This document becomes your routing logic. If you skip it, you end up building the automation three times.

4. Downstream system access
Know where qualified candidates go after screening. HRIS? A shared Slack channel? A hiring manager’s inbox? A calendar booking link? Each destination needs its own connection in Make.com, and each requires credentials you’ll want ready before you start.

5. A test candidate record
Create a dummy applicant in your ATS before you build. You’ll need it to test every step without polluting your real pipeline.

Step 1: Set Up Your ATS Webhook or Polling Trigger

Make.com needs to know when a new application arrives. There are two ways to do this: webhook (ATS pushes data to Make the moment it happens) or polling (Make checks your ATS on a schedule). Webhooks are faster and more reliable — use them if your ATS supports them.

Webhook setup (preferred)

1. In Make.com, create a new scenario and add a Webhook module as the trigger.
2. Copy the generated webhook URL Make.com provides.
3. In your ATS settings, find the webhooks or integrations section and paste that URL as the endpoint for “new application” events.
4. Trigger a test application to confirm Make.com receives the payload.
5. Map the fields from the incoming payload (applicant name, email, role applied for, resume URL, custom form answers) — you’ll reference these in later steps.

Polling setup (fallback)

1. Use your ATS’s native Make.com module (search the Make.com module library for your ATS name) or an HTTP module hitting your ATS’s REST API.
2. Set the trigger to run every 5–15 minutes.
3. Use a filter to catch only applications newer than the last run timestamp — most ATS APIs support a created_after parameter.
4. Store the last-run timestamp in a Make.com data store so subsequent runs don’t reprocess old applications.

Name this module clearly. “Watch New Applications — [ATS Name]” is better than leaving it as the default module name. Every module in your scenario gets a clear name — this makes debugging faster when something breaks at 2am before a hire deadline.

Step 2: Build Your Screening Logic Filter

The filter is where your screening criteria document becomes code. Make.com’s built-in filter blocks are enough for most use cases — you don’t need a custom API call unless your logic is complex.

Simple filter (rule-based)

Add a Filter module immediately after your trigger. Set conditions based on the fields you mapped in Step 1. Examples:

• Required field present: Years of Experience is greater than or equal to 3
• Location match: Location contains remote OR equals Austin, TX
• Role match: Job Title equals Operations Manager

Applications that don’t pass the filter stop here. No further modules run for them. That’s intentional — you don’t need to send automated rejections at this stage (more on that in Common Mistakes).

Scoring logic (optional, higher accuracy)

If you have more than five criteria or want a weighted score rather than a pass/fail gate, use Make.com’s Tools > Set Variable modules to calculate a numeric score. Assign points per criteria met, then route based on score ranges:

• Score 8–10: Route to immediate hiring manager notification
• Score 5–7: Route to recruiter review queue
• Score 0–4: Stop (no action)

Document the scoring logic in a Make.com note attached to the module so anyone who touches the scenario later knows how it works.

Step 3: Route Qualified Candidates to the Right Destination

Once an applicant passes the filter, the scenario needs to send them somewhere useful. The most common destinations are a Slack notification, an email to the hiring manager, a task in your project management tool, or a record update back in the ATS itself.

Slack notification

Add the Make.com Slack module, connect your workspace, and select the target channel. Build the message to include: applicant name, role, a link to their ATS record, and the score (if you built scoring logic). Set the sent_from field in the message footer to the current scenario URL so the team can trace any candidate back to the specific run that triggered the alert.

Email to hiring manager

Use the Gmail or SMTP module. Build a templated email with the applicant summary, a direct link to the resume, and a one-click link to your calendar booking tool. Include the Make.com execution URL in the email footer — this is standard practice and makes audit trails trivial.

ATS status update

Use your ATS’s write API to move the applicant to the next stage automatically. This keeps your ATS pipeline current without manual drag-and-drop. Most ATS APIs support a PATCH or PUT request to update stage — use an HTTP module if a native Make.com ATS module isn’t available for your platform.

Every HTTP POST module in this scenario must include two fields in the request body: sent_from (the URL of this Make.com scenario) and sent_to (the endpoint receiving the data). This is non-negotiable for traceability when something goes wrong.

Step 4: Add Error Handling

Error handling is the step most teams skip and regret. An unhandled API timeout or a rejected webhook payload means a qualified candidate disappears from the pipeline silently.

Standard error handler setup

1. Right-click any external API module in Make.com and select Add error handler.
2. Choose Break as the handler type.
3. Set retry to 3 attempts with a 60-second interval between retries.
4. Add a fallback notification — a Slack message or email to the recruiting ops owner — that fires if all three retries fail.

Apply this pattern to every external API call: your ATS module, Slack, Gmail, and any HRIS write operations. The 3-attempt / 60-second interval is the 4Spot standard and catches the majority of transient API failures without human intervention.

Step 5: Test End-to-End Before Going Live

Use your dummy applicant from the prerequisites phase to run the full scenario manually before activating it.

Test checklist

• Trigger fires correctly when test application is submitted
• Filter correctly passes or blocks based on test data
• Qualified candidate notification reaches the right channel/inbox
• ATS stage updates to the correct next step
• Error handler fires correctly when you intentionally break the API connection
• All module names are descriptive (not “HTTP 3” or “Slack 2”)
• All HTTP POST modules include sent_from and sent_to fields

Run the test at least twice: once with a candidate who should pass, once with a candidate who should be filtered out. Confirm both behave correctly before flipping the scenario active.

How to Know It Worked

Activation isn’t the finish line. Here’s what confirms the system is actually running correctly after go-live.

Week 1 metrics to track

• Trigger count vs. ATS new applications: These numbers should match within the polling interval. A gap means the trigger is missing applications.
• Filter pass rate: If 95%+ of applications are passing the filter, your criteria are too loose. If 0% pass, something in the field mapping broke.
• Time to first notification: Measure the gap between application submission and the Slack/email alert. Target under 15 minutes for polling, under 2 minutes for webhooks.
• Error log in Make.com: Check the scenario history daily for the first two weeks. Every incomplete run gets investigated.

Nick, a recruiter at a small firm, tracked these metrics after setting up a similar pipeline and reclaimed 15 hours per week — roughly 150+ hours per month across his team of three. The time savings came directly from eliminating the manual review triage that this automation now handles.

What Are the Most Common Mistakes Teams Make?

Three mistakes account for the majority of failed ATS integrations — and all three are avoidable.

Mistake 1: Automating the rejection email too early

Sending automated rejections at the filter stage is a candidate experience risk. If your filter has a bug, you reject qualified people. Build the notification and routing first, prove it works for 30 days, then add rejection automation — and even then, only for applications that clear an obvious minimum bar.

Mistake 2: Skipping field mapping documentation

ATS APIs return different field names depending on version and configuration. If you don’t document which field in Make.com maps to which ATS field — and what the expected data format is — the scenario becomes unmaintainable. Use Make.com notes on every field mapping module. Future-you will be grateful.

Mistake 3: No error notifications

A scenario that breaks silently is worse than no automation at all. Add a fallback Slack alert or email that fires when any module fails after exhausting retries. Without it, qualified candidates fall into a void and nobody knows until a hiring manager asks why the pipeline is empty.

For teams looking to expand beyond screening, 11 ATS Automation Strategies for Recruiting Teams in 2026 covers the next layer of what’s buildable once the foundation is solid. And if you’re evaluating whether Make.com is the right platform for this work versus alternatives, Cost-Effective HR Automation: Make.com vs. Zapier Pricing Showdown breaks down the real cost differences at scale.

Frequently Asked Questions

Does my ATS need a native Make.com integration to connect?

No. If your ATS has a REST API (almost all modern platforms do), you connect it through Make.com’s HTTP module using API key authentication. Native Make.com modules exist for popular platforms like Greenhouse, Lever, and Workable, but they’re a convenience — not a requirement. The HTTP module handles any ATS with a documented API.

How long does it take to build this integration?

A basic webhook trigger, filter, and Slack notification takes two to four hours for someone familiar with Make.com. Adding ATS stage updates and error handling adds another two hours. Plan for one full day to build, test, and document a complete setup from scratch.

What happens to applications that don’t pass the screening filter?

Nothing — by design. The Make.com filter stops processing for applications that don’t meet your criteria. No automated rejection fires unless you build one explicitly. For most teams, the right approach is to leave non-passing applications in the ATS for periodic human review rather than automating rejections at the filtering stage.

Can this integration break if the ATS vendor updates their API?

Yes, and this is the most common maintenance issue. ATS vendors version their APIs, and field names or endpoint structures change between versions. Subscribe to your ATS vendor’s API changelog. When they announce a version change, audit your Make.com field mappings before the cutover date. The documentation you created during setup makes this audit straightforward.

Is Make.com secure enough to handle candidate data?

Make.com is SOC 2 Type II certified and GDPR compliant. Candidate data flowing through Make.com scenarios is encrypted in transit and at rest. Review your ATS vendor’s data processing agreement to confirm they permit outbound webhook connections to third-party automation platforms — most do, but it’s worth verifying for compliance documentation.

How do I handle high-volume roles where hundreds of applications come in at once?

Make.com processes scenario executions sequentially by default. For high-volume roles, enable the parallel processing option in your scenario settings (available on paid plans). This lets multiple applications process simultaneously. Also set your filter criteria tighter for high-volume roles so the system routes fewer candidates to human review and more stop cleanly at the filter.

Do I need a developer to maintain this after it’s built?

No. Make.com’s visual interface lets a recruiter or HR ops person adjust filter criteria, update routing destinations, or swap notification templates without writing code. The initial build benefits from someone comfortable with APIs and JSON, but day-to-day maintenance is non-technical. Clear module naming and documentation notes during the build phase make self-service maintenance realistic.