TL;DR

Webhooks are HTTP callbacks that send real-time notifications from one system to another when a specific event occurs. Instead of repeatedly asking an ATS whether anything has changed (polling), the ATS pushes a notification to your system the moment a candidate advances to a new stage, a job is filled, or an offer is accepted. In recruitment technology, webhooks are the mechanism behind real-time integration between ATS platforms, sourcing tools, analytics dashboards, and communication systems.

How Webhooks Work

Webhooks invert the typical request-response model. In a normal REST API interaction, your system asks the ATS for data, and the ATS responds. With webhooks, you register a URL (your endpoint) with the ATS and declare which events you want to be notified about. When that event happens, the ATS sends an HTTP POST request to your URL with a JSON payload describing what changed. Your system receives it, processes it, and responds with a 200 OK. No polling required.

The payload typically contains the event type, a timestamp, and relevant entity data. When Greenhouse fires a webhook for a candidate stage change, the payload includes the candidate ID, the previous stage, the new stage, the job ID, and the user who triggered the change. A receiving system can parse this payload and immediately update its own records, trigger a downstream workflow, send a notification, or log the event to an analytics pipeline.

Reliability is a real design concern. HTTP POST requests can fail - the receiving server might be down, the network might time out, the receiving application might have a bug. Webhook providers handle this differently. Greenhouse retries failed webhooks up to several times with exponential backoff. Lever marks failed deliveries in a log, and you can retry manually. Bullhorn's event notification system has configurable retry behavior. Any production webhook consumer needs to handle duplicate delivery gracefully - the same event might arrive twice if the first delivery timed out before the response was received.

Security for webhooks requires verifying that the incoming request actually came from the ATS and not from a spoofed source. The standard approach is a shared secret: the ATS signs the payload with an HMAC (Hash-based Message Authentication Code) using a secret you both agreed on, and includes the signature in a request header. Your receiving application recomputes the HMAC from the raw request body and compares it to the header. If they match, the request is authentic. Greenhouse, Lever, and Bullhorn all support HMAC signature verification.

Why It Matters in Recruitment

Polling-based integrations are expensive, slow, and fragile. An analytics tool that checks the ATS every 5 minutes for new candidate activity sends 288 API requests per day, uses up rate limit quota, and still has data that's up to 5 minutes stale. A webhook-based integration receives updates within seconds of the event and makes zero API calls for events that don't happen. For high-volume staffing agencies running thousands of active applications at a time, the operational difference is significant.

Real-time data matters for specific recruitment workflows. When a candidate accepts an offer in the ATS, a webhook can immediately trigger the background check initiation in the background check vendor, send a welcome email from the HRIS, and notify the hiring manager via Slack - all before the recruiter has finished the current call. Chaining these automations through webhooks collapses a 30-minute manual workflow to under 30 seconds.

For reporting and analytics, webhooks enable genuinely real-time dashboards rather than delayed snapshots. A recruitment operations team monitoring pipeline velocity across 20 client accounts can see candidate movements reflected in their dashboard as they happen, not the following morning after an overnight ETL job. This matters most during high-volume hiring periods where pipeline bottlenecks need to be identified and cleared in hours, not days.

Webhooks in Practice

A [staffing agency](/glossary/staffing-agency)'s tech team builds an integration between Bullhorn and their internal SLA monitoring tool. The SLA tool needs to flag any candidate who has been in an "Interview Scheduled" stage for more than 48 hours without an outcome recorded. They register a webhook in Bullhorn for CandidateInterview events. Every time an interview is created or updated, Bullhorn POSTs the event to https://internal-sla-tool.agency.com/webhooks/bullhorn.

The SLA tool's endpoint validates the HMAC signature, parses the event, and records the interview in its own database with a 48-hour countdown timer. When a separate CandidateInterview event comes in showing the interview resolved, the countdown is cleared. If no resolution event arrives within 48 hours, the SLA tool sends an alert to the recruiter's manager. The entire flow runs on incoming events - no API polling, no scheduled queries.

Key Considerations