Recruiting Basics

Webhook

A webhook is an automatic message one system sends to another the instant something happens. When an event occurs, the sending system posts a small package of data to a web address the receiving system supplied in advance, so the second system learns about the change immediately instead of asking repeatedly.

How is a webhook different from polling an API?

Polling means the receiving system asks on a schedule: every few minutes it calls the other system and enquires whether anything changed. A webhook reverses that direction. Nothing is asked, because the sending system announces the change as it happens by posting to a URL the receiver gave it earlier. The practical differences are timing and waste. Polling introduces a delay equal to the interval, and almost every check returns nothing, which burns request limits on both sides. Webhooks arrive within seconds and only when there is something to say. The trade-off is reliability, since a webhook firing while the receiver is offline can be lost unless the sender retries, whereas a poller simply catches up on its next run. Careful integrations use both, with webhooks for speed and a periodic reconciliation sweep to catch anything missed.

Which recruiting events typically trigger a webhook?

Anything marking a change of state in the hiring process. New application received is the most common, because it lets a downstream tool react the moment somebody applies. Candidate stage changed drives notifications, assessment orders and scheduling. Interview scheduled or canceled keeps a calendar or a video tool in step. Offer extended, accepted or declined is the event that usually triggers work outside recruiting, such as creating a record for onboarding. Requisition opened, approved or closed feeds finance and workforce planning. The package that arrives is normally compact: an event name, a timestamp, identifiers, and enough detail for the receiver to fetch the full record if it needs more. That last point surprises people. A webhook usually tells you what happened rather than shipping an entire candidate profile, so the receiving system still calls back for the details.

What happens when a webhook fails to arrive?

Well-behaved senders retry, usually several times with a widening gap between attempts, then stop after a set number of failures. That behavior creates the two situations every implementation has to handle. The first is a message that never lands, because the receiver was unavailable for longer than the retry window, which is why a scheduled reconciliation job earns its keep even when webhooks work. The second is the same message arriving twice, since a retry can fire after the original was in fact processed. The remedy is idempotency: the receiver records the event identifier and ignores anything already handled, so a repeat delivery changes nothing. Ask for a delivery log as well. Without visibility into which events were sent and what response came back, a silently failing webhook looks exactly like a system where nothing is happening.

Who sets up a webhook, and what do you need to provide?

Someone technical on the receiving side, usually a developer, an implementation consultant, or the vendor whose tool is consuming the events. The recruiting team's job is to specify which events matter and what should happen when they arrive, which is a business decision rather than a technical one. What gets exchanged is short: the destination URL, the list of events to subscribe to, and a shared secret so the receiver can verify a message genuinely came from the sender rather than from someone who guessed the address. Expect a test event, a staging environment if one exists, and a conversation about failure handling. If nobody can own the receiving end, a native connector shipped with your [hiring software](/hiring-software) is the better route, and that wider buying question belongs to the ATS integration decision rather than to this mechanic. Webhooks are simply the plumbing beneath most cross-system [recruitment automation](/recruitment-automation).

See how Pitch N Hire handles webhook on your roles

Choosing your recruiting stack

Next step

FAQ

Webhook — FAQs

Do you need a developer to use webhooks? +
To build the receiving end, yes, or a vendor who provides one. Many recruiting tools already accept webhooks from common systems, in which case setup is pasting a URL and choosing events, which a capable administrator can handle. The developer requirement appears when the destination is something you built yourself or when the incoming data needs processing before use.
Can a webhook send data into an ATS as well as out of it? +
The webhook itself only pushes an event outward. Writing into a recruiting system normally means calling its API, which is a different mechanic. Some vendors also offer inbound endpoints that accept posted data and behave similarly from the outside. Check the direction supported for each event you care about, because outbound coverage is usually broader than inbound.
Are webhooks secure? +
They can be, with two standard precautions. The endpoint should be served over an encrypted connection, and the sender should sign each message with a shared secret so the receiver can verify it. Without verification, anyone who learns the address can post convincing fake events. Treat the URL as a credential, rotate the secret if it leaks, and log rejected deliveries.
What happens if the same event is delivered twice? +
Nothing should, provided the receiver expects it. Duplicate delivery is normal, because senders retry when they do not get a clear success response, sometimes after the message was already processed. Storing the event identifier and skipping anything already seen prevents duplicate records, duplicate emails and duplicate stage moves. Ask how this is handled before going live.
Built for recruiters & hiring teams

See Webhook in action

Pitch N Hire unifies sourcing, screening and hiring decisions on one AI-native platform. Book a quick demo on your real roles.

Prefer to talk? Book a demo · View pricing

Free 1-user plan · No credit card · Talk to a real hiring expert

One Hiring Infrastructure.
Zero Tool Chaos.

Demos are consultative. We respect privacy and enterprise
governance. No lock-ins.

Start free Book demo