How to Set Up Real-Time HR Webhooks in Make.com™: Step-by-Step Guide

Batch-processed HR workflows have a latency problem no amount of staffing fixes. Every minute between an event — a new hire accepting an offer, a termination being approved, a leave request submitted — and the downstream actions that event should trigger is a minute where data is out of sync, systems disagree, and people are waiting. The solution is not a faster schedule. It is an event-driven trigger: a webhook.

This guide walks you through the exact steps to build a production-ready, webhook-triggered HR automation scenario in Make.com™. If you are still deciding whether webhooks are the right trigger layer for your use case, start with the parent pillar on webhooks vs. mailhooks in Make.com™ HR automation before continuing here.

Before You Start

Completing this guide requires the following. Confirm each item before opening Make.com™.

  • Make.com™ account with an active plan. The free tier supports webhook triggers; confirm your operation limits are sufficient for expected event volume.
  • Admin or integration access to your source HR system (HRIS or ATS). You need permission to create outbound webhooks or event notifications in that system’s settings.
  • A destination system and credentials. Know which system should receive the data (e.g., HRIS, Slack workspace, Google Sheets, email service) and confirm you have the API key or connection credentials to add it as a Make.com™ module.
  • A sample event payload. If your source system documents its webhook JSON structure, have that open. If not, you will capture it live in Step 3.
  • Time estimate: 25–40 minutes for a single-event, single-destination scenario. Add 15–20 minutes per additional event type or destination branch.
  • Risk note: Build and fully test in a staging or sandbox environment before connecting a production HRIS. A misconfigured field mapping that overwrites live employee records is harder to fix than a missed test.

Step 1 — Create a New Scenario and Add the Webhook Trigger

Open Make.com™ and create a new scenario from the Scenarios dashboard. When prompted to choose a trigger, search for Webhooks and select the Custom Webhook module.

In the module configuration panel, click Add to generate a new webhook. Give it a descriptive name tied to the HR event it will receive — for example, “ATS New Application Received” or “HRIS Employee Status Changed.” Make.com™ will generate a unique HTTPS endpoint URL.

Copy this URL immediately. It is the address your source system will POST event data to. Treat it like a credential — it is specific to this scenario and this webhook.

At this stage, do not click Run Once yet. Leave the scenario paused and move to Step 2.

What makes this step critical

The generated URL is unique and persistent as long as the webhook exists. Deleting and recreating a webhook generates a new URL, which means updating every source system that uses the old one. Name your webhooks precisely from day one to avoid confusion when managing multiple HR automation scenarios.

Step 2 — Register the Webhook URL in Your Source HR System

Navigate to your source HR system’s integration or developer settings. The exact path varies by platform, but look for labels like Webhooks, Event Notifications, or Outbound Integrations.

Create a new webhook entry and paste the Make.com™ endpoint URL into the destination URL field. Then configure which event types should trigger this webhook. For an onboarding use case, you might select:

  • Offer accepted / candidate hired
  • Employee record created
  • Onboarding status changed

Save the configuration. Most platforms will immediately send a verification ping or test payload to confirm the endpoint is reachable. Make.com™ will receive this — you will see it in Step 3.

If your source system requires HTTPS verification: Make.com™ webhooks are HTTPS by default. No additional SSL setup is needed on the Make.com™ side.

For teams evaluating whether this trigger approach is right for high-frequency HR events, the guide on why real-time HR workflows demand webhooks over polling provides the architectural comparison in depth.

Step 3 — Capture and Inspect the Incoming Payload

Return to Make.com™ and click Run Once on your scenario. This puts the webhook into a listening state for one execution cycle. Go to your source HR system and trigger a test event — create a test candidate record, simulate an offer acceptance, or use the platform’s built-in “Send Test” function if available.

Within seconds, Make.com™ will display the received data in the webhook module’s output panel. This is the raw JSON payload your source system sent.

Examine the payload structure carefully. Identify:

  • The field names for employee data you need (first name, last name, email, employee ID, start date, position, etc.)
  • Any nested objects (e.g., candidate.contact.email vs. a flat email field)
  • An event type identifier field if the system sends multiple event types to the same URL
  • Any fields that may be null or absent depending on the event type

Document this structure. The accuracy of your field mapping in Step 4 depends entirely on understanding what the source system actually sends versus what its documentation says it sends. These are not always identical.

Based on our testing, approximately 30% of payload structures differ from what vendor documentation describes — either due to platform version differences or optional fields that only appear under specific conditions.

Step 4 — Map Payload Fields to Destination Modules

With the payload structure confirmed, add the modules that will act on the data. Click the + button after the webhook trigger to add your first action module. Common first actions for HR webhook scenarios include:

  • HRIS create/update record — push employee data from the ATS into the HRIS
  • Send email notification — alert HR, IT, or the hiring manager
  • Create a row in a spreadsheet or database — log the event for reporting
  • Post a Slack message — notify the onboarding team in real time

For each module, use the field mapping panel to connect incoming webhook data to the module’s required inputs. Click into any input field and use the variable picker to select the corresponding field from the webhook payload output.

Mapping precision matters here more than anywhere else in the scenario. McKinsey Global Institute research identifies data inconsistency as a primary drag on knowledge worker productivity. A single mismatched field — employee ID mapped to a name field, for instance — can corrupt records across every downstream system the scenario touches. Map every field explicitly. Do not rely on auto-mapping.

For HR onboarding workflows specifically, the guide on HR onboarding automation with Make.com™ webhooks covers the standard module sequence and field mapping patterns in detail.

Step 5 — Add a Router for Event-Type Branching

If your webhook endpoint will receive more than one event type — which is the case for most production HR scenarios — insert a Router module immediately after the webhook trigger, before any action modules.

Each Router branch handles one event type. Set the branch filter to match the event type identifier field from the payload (e.g., event_type equals "new_hire", "termination", "leave_approved"). Then build the appropriate action sequence on each branch independently.

This architecture prevents null-field errors that occur when a field present in one event type is absent in another. Without a Router, a termination event missing a start_date field will break a scenario built expecting that field for new hires.

Add a final Router branch with no filter — a catch-all — that routes unrecognized event types to a logging action. This ensures no event silently disappears.

Step 6 — Configure Error Handling

Production HR automation without error handling is not production-ready. Destination systems go offline. APIs hit rate limits. Required fields arrive null. Every route in your scenario needs a defined behavior for when something goes wrong.

In Make.com™, right-click any module to add an error handler. The two most useful configurations for HR webhooks:

  • Resume: logs the error, skips the failed module, and continues the scenario. Use this for non-critical notifications where a missed alert is acceptable.
  • Rollback: reverses any committed transactions in the current execution. Use this when partial writes to the HRIS would leave data in an inconsistent state.

On every error handler, add a notification action — a Slack message, an email, or a log entry to a dedicated error-tracking sheet. Asana’s Anatomy of Work research found that workers spend a significant portion of their week tracking down status on work that should be complete. Silent automation failures are the primary cause of that ambiguity in HR operations.

For a comprehensive treatment of failure modes and recovery patterns, the webhook failure troubleshooting guide for HR automation covers every common scenario.

Step 7 — Set Sequential Processing (If Required)

By default, Make.com™ processes incoming webhooks concurrently — multiple events arriving within the same execution window will run in parallel. For most HR notifications, this is ideal: speed is the point.

However, some HR workflows require sequential execution to prevent race conditions. The clearest example: if two systems are simultaneously updating the same employee record, a parallel execution can cause the second write to overwrite the first before either completes.

To enforce sequential processing, open the webhook module settings and toggle Sequential Processing to on. Executions will queue and process one at a time. The tradeoff is throughput — if you are processing high volumes of events (mass onboarding, open enrollment changes), sequential processing will create a queue. For high-volume scenarios, the guide on scaling webhook scenarios for high-volume HR events covers queue management and parallel architecture patterns.

How to Know It Worked: Verification

Do not assume. Verify. A webhook scenario that appears to run without errors can still silently deliver incorrect data if field mapping is wrong. Run this verification sequence before activating the scenario for production use.

Verification checklist

  1. Trigger a live test event in your source HR system — not a synthetic test, an actual event of the type the scenario is designed to handle.
  2. Open the Make.com™ History tab and confirm the execution appears with a green status indicator. Click into the execution record and inspect each module’s input and output values.
  3. Check the destination system directly. Log into your HRIS, Slack workspace, or email account and confirm the expected record was created, message was sent, or row was written — with the correct field values, not placeholder or null values.
  4. Trigger an intentional error — send a malformed or incomplete event — and confirm your error handler fires and the notification reaches the right channel.
  5. Confirm no duplicate records were created. Webhooks can occasionally fire twice if the source system has retry logic. If duplicates appear, add a deduplication filter using the event’s unique ID field before write modules.

If all five checks pass, the scenario is production-ready. Toggle it to Active.

Common Mistakes and Troubleshooting

Mistake 1: Activating without a live test

Running Make.com™’s internal “Run Once” test with a manually constructed payload is not sufficient. The source system’s actual payload often differs from what you expect. Always trigger a real event before activating.

Mistake 2: No Router, one scenario for all event types

Handling multiple event types on a single linear path is the most common structural error. The first event type that sends a field the others do not will break every subsequent execution until someone investigates. Build the Router from the start.

Mistake 3: Ignoring the Incomplete Executions queue

Make.com™ stores failed executions in an Incomplete Executions queue by default. Without a process to review this queue — or an error handler that sends notifications — failures accumulate invisibly. Parseur’s research on manual data handling indicates that undetected errors in data pipelines compound downstream costs significantly. Set a standing calendar reminder to audit the queue weekly until you have confirmed error handling is complete.

Mistake 4: Using the same webhook URL for multiple unrelated scenarios

One webhook URL, one scenario. Routing logic belongs inside Make.com™, not outside it. Sharing a webhook URL across unrelated scenarios creates dependency and debugging complexity that scales badly.

Mistake 5: Not accounting for payload schema changes

Source HR systems update their API schemas. A field that existed when you built the scenario may be renamed or nested differently after a platform update. Add the scenario to a quarterly review cadence and subscribe to the source system’s API changelog.

Next Steps: Scaling and Layering Logic

A working single-event webhook scenario is the foundation, not the ceiling. Once the core pipeline is stable, consider these extensions:

  • Add conditional filters within each Router branch to handle edge cases (e.g., fire a different notification for executive hires vs. individual contributor hires).
  • Introduce data transformation — use Make.com™’s built-in text and date functions to normalize field formats before writing to destination systems.
  • Chain scenarios — use one webhook scenario’s output to trigger a second scenario via another webhook. This keeps individual scenarios focused and maintainable.
  • Layer AI judgment only after the deterministic pipeline is confirmed. As the parent pillar on webhooks vs. mailhooks in Make.com™ HR automation establishes: AI on top of a broken trigger layer amplifies chaos. AI on top of a working webhook pipeline amplifies results.

For a real-world example of this architecture in action, the case study on automating employee feedback with Make.com™ webhooks shows the full build — including the routing logic and error handling patterns described in this guide — applied to a live HR feedback cycle.

For HR teams managing time-sensitive compliance events, the guide on using real-time webhooks for critical HR alerts covers the alert-routing patterns that keep HR leadership informed without creating notification fatigue.