Webhooks in Make.com connect your ATS and HRIS in real time — eliminating the re-keying lag that turns a single offer-letter typo into a five-figure payroll error. This guide covers the exact build sequence: webhook listener creation, payload mapping, conditional routing, and safe activation against live HR data.

Your ATS knows the moment a candidate accepts an offer. Your HRIS does not find out until someone re-keys it — usually hours or days later, occasionally with a typo that costs tens of thousands of dollars to fix. That gap is not a technology problem. It is a process problem, and it is the problem webhooks in Make.com were built to close.

This guide is the operational companion to How a Non-Technical HR Team Started Building Their Own Automations With Make + AI. Where that resource covers the strategic landscape, this one gives you a precise build sequence for connecting HR systems through real-time webhook triggers — no code required.

What Webhooks Do That Scheduled Pulls Cannot

A scheduled poll asks your source system “did anything change?” on a fixed interval — every 15 minutes, every hour. A webhook flips that: the source system tells Make.com the moment something changes.

For HR workflows, the difference is material:

• Offer accepted at 9:03 AM → HRIS new-hire record exists at 9:03 AM, not at 9:15 or 10:00
• Background check cleared → onboarding task sequence fires immediately, not at the next poll window
• I-9 submitted → compliance log updated in real time, not in batch

The $27K overpayment case documented in The $27K Overpayment: How One HRIS Data Entry Mistake Cost a Manufacturer a Year of Salary traces directly to re-keying delay and human error between systems. A webhook integration eliminates both failure modes.

Prerequisites Before You Build

Webhooks are production integrations, not experiments. Confirm all of the following before opening Make.com:

• Admin access to your source system. You need developer or admin-level access to your ATS, HRIS, or triggering platform to configure outbound webhooks. Read-only access is not sufficient.
• A paid Make.com plan. Any paid tier supports webhooks at production volume. The free tier has execution and data-store restrictions that make it unsuitable for HR production workloads.
• Target system credentials. Gather API keys, OAuth tokens, or login credentials for every system your workflow writes to. Test authentication before building.
• A sample payload. Identify a real or realistic test record in your source system you can use to fire a test event. You need this in Step 3.
• A test environment or sandbox record. A misconfigured webhook writing bad data to your HRIS is worse than no integration. Build against a sandbox before activating on live production data.

Time estimate: Plan 60–90 minutes for a first build. Scenarios with multiple routing branches take 2–3 hours plus testing time.

Step 1: Identify the Trigger Event and Source System

Define the exact HR event that starts your workflow before touching Make.com. Vague triggers produce fragile integrations.

Answer three questions:

1. What event? Candidate status changed to “Hired.” Offer letter signed. Background check completed. Interview scheduled. Be specific — “something happened in the ATS” is not a trigger.
2. Which system fires it? Your ATS, e-signature tool, scheduling platform, or LMS. Each source system has its own webhook configuration and its own payload structure.
3. Does the source system support outbound webhooks natively? Most modern ATS platforms do. Check your platform’s developer documentation. If native webhooks are unavailable, Make.com can poll the system’s REST API on a schedule — functional for lower-urgency workflows like weekly compliance reporting, but not for same-day HRIS sync.

Highest-ROI starting points for HR teams:

• ATS candidate status → “Hired” → trigger HRIS new-hire record creation
• E-signature platform → offer letter signed → trigger onboarding task sequence
• Scheduling tool → interview confirmed → trigger calendar event + candidate confirmation email

Document your chosen trigger and source system before moving to Step 2. You will reference this throughout the build.

Step 2: Create the Make.com Webhook Listener

The webhook listener is the URL Make.com generates to receive inbound data from your source system. Creating it takes under five minutes.

1. Log into Make.com and create a new scenario.
2. Click the trigger module (the leftmost circle) and search for Webhooks.
3. Select Custom Webhook from the Webhooks module list.
4. Click Add to create a new webhook and give it a descriptive name — for example, “ATS Hired Status — HRIS Sync”.
5. Make.com generates a unique webhook URL. Copy it. This is what you paste into your source system.
6. Leave the scenario open. Make.com enters “waiting for data” mode, which you need for Step 3.

Step 3: Fire a Test Payload and Capture the Structure

Make.com cannot map fields it has never seen. You need to send a real event from your source system to teach Make.com what data arrives.

1. In your source system, navigate to the webhook or developer settings.
2. Paste the Make.com webhook URL from Step 2 into the destination field.
3. Configure the trigger condition — the specific event that fires the webhook (e.g., “candidate status = Hired”).
4. Trigger a test event. In most ATS platforms, this is a “Send Test” button or manually changing a test record’s status.
5. Return to Make.com. The scenario displays the captured payload — every field your source system sends.
6. Click OK to accept the data structure. Make.com now knows the shape of your data.

If your source system does not have a “Send Test” button, manually trigger the event with a test record. Never use a real active candidate’s record for initial testing.

Step 4: Map Fields and Build the Target System Action

With the payload captured, add the action module that writes data to your target system.

1. Click the + button to add a module after your webhook trigger.
2. Search for your target system — BambooHR, Workday, ADP, or a generic HTTP module for systems without a native Make.com connector.
3. Select the appropriate action: typically Create Record or Update Record.
4. Authenticate using the credentials gathered in the prerequisites step.
5. Map each required field: click into the field, then select the corresponding value from your webhook payload. Make.com displays available payload variables in a dropdown.
6. Map all required fields first, then optional fields. Leave fields blank rather than mapping incorrect data.

For HRIS new-hire creation, the minimum required fields are: first name, last name, start date, department, job title, and employment type. Confirm your HRIS’s required fields before mapping.

Step 5: Add Conditional Routing for Edge Cases

Real HR data is messy. Not every “Hired” trigger follows the same path. A router module handles this without building parallel scenarios.

Common routing conditions for HR webhook workflows:

• Employment type: Full-time vs. contractor routes to different HRIS record types and different onboarding sequences
• Department: Engineering hires route to IT provisioning; sales hires route to CRM access requests
• Location: Remote hires skip facilities requests; on-site hires trigger equipment orders
• Rehire flag: Returning employees skip background check initiation if within the re-hire window

1. Click the + after your webhook trigger (before the HRIS module) and add a Router module.
2. Define each route with a filter condition based on payload fields.
3. Connect the appropriate action module to each route.
4. Add a catch-all route (no filter condition) to handle records that match no specific condition — route these to a Slack notification or email alert for manual review.

Step 6: Test End-to-End, Then Activate

Run a full end-to-end test before activating against live data.

1. Use your test record from Step 3 to fire the webhook again.
2. Watch Make.com execute the scenario in real time — each module shows a green check (success) or red X (error).
3. Verify the record was created or updated correctly in your target system.
4. Check edge-case routes with records that match each routing condition.
5. Confirm the catch-all route fires for an unmatched record.
6. Once all routes pass, click Activate scenario in the Make.com interface.

Activation is not irreversible. You can pause or deactivate a scenario instantly from the Make.com dashboard if something behaves unexpectedly in production.

What to Build After Your First Webhook Integration

The ATS → HRIS sync is the right first build: high impact, consistent payload structure. Once it runs cleanly for two weeks, these are the logical next builds:

• Offer letter signed → onboarding checklist created in your project management tool, assigned to HR and IT with due dates tied to start date
• Background check completed → status update sent to hiring manager via Slack or email with next-step instructions
• New hire start date T-7 → equipment order triggered to IT with role-specific provisioning list
• Termination processed → access revocation queue created and routed to IT security with timestamp

Each follows the same six-step build sequence. The difference is the source system, the payload structure, and the routing conditions. For a broader view of what HR teams are building with Make.com today, see 6 Ways the Make MCP Changes Automation Work for HR Teams.

Frequently Asked Questions

Does my ATS need native webhook support to use this approach?

No. If your ATS does not support outbound webhooks natively, Make.com can poll the ATS REST API on a schedule — every 5, 15, or 60 minutes depending on your plan and urgency. For same-day HRIS sync, native webhooks are the better path. For weekly reports or lower-urgency transfers, polling works fine.

What happens if Make.com is down when an event fires?

Make.com queues incoming webhook payloads when a scenario is inactive and replays them when the scenario resumes — up to the data retention limit on your plan. For mission-critical HR workflows, configure a redundant notification (email or Slack) in your source system so you know if a webhook event did not result in a Make.com execution.

Can I connect multiple source systems to one Make.com scenario?

Each Make.com scenario has one trigger. If you need to react to events from two different source systems, build two scenarios — one per source — and route both to a shared webhook or data store for downstream processing. This keeps debugging clean and error handling precise.

What should I do if the payload structure changes after a source system update?

Re-run the test payload capture from Step 3 after any source system update that touches fields your scenario uses. Make.com stores the original data structure — if new fields appear, remap. If old fields disappear, modules using them show errors. Review the scenario after every source system update.

Is this approach secure for sensitive HR data like SSNs or compensation?

Make.com webhook URLs are unique and not guessable, but they are not authenticated by default. For sensitive HR data, use IP allowlisting on the source system side to restrict which IPs can call your Make.com webhook. Avoid transmitting SSNs or compensation data via webhook payload — pass employee IDs and let the HRIS module fetch sensitive fields directly via authenticated API call.