INTEGRATIONS · EXPERTINI ATS

Webhooks

POST real-time hiring events to any URL — the raw material Zapier, n8n, and Make are built on.

2 min read · Updated July 2026 · Expertini Editorial

Every hiring team has a system the ATS cannot see: a data warehouse, an internal dashboard, a home-grown tool that needs to know when something happened. Webhooks are the universal answer. When a job is published, an application arrives, or a candidate changes stage, Expertini ATS POSTs a structured JSON event to any URL you configure — in real time, as the event happens.

The gap this closes is the polling problem: without events, external systems either check repeatedly for changes or fall out of date. Webhooks invert that — your systems are told, immediately, and only when there is something to know. This is the same primitive that automation platforms like Zapier, n8n, and Make are built on, which means one webhook endpoint can fan your hiring events out to practically any tool those platforms support. It ships natively in your subscription: no automation add-on tier, no per-event pricing, no separate integration product. Deliveries are fired asynchronously, so heavy downstream systems never slow down your recruiters or your hiring pipeline.

▶ Watch the 30-second overview — no sign-up needed

01Events that map to real hiring moments

The events cover the moments teams actually automate around: a job going live, a new application landing, a candidate moving between stages. Each delivery is a JSON payload with the relevant records, sent to your URL the moment the event occurs.

From those three primitives, teams build a lot: instant notifications to internal channels, nightly-report replacements, SLA timers on stage changes, and warehouse feeds that keep BI dashboards current without exports.

02Bring your own automation platform — or none

Point the webhook at a Zapier, n8n, or Make trigger URL and your hiring events enter ecosystems of thousands of apps with no code at all. Or skip the middleman: any HTTPS endpoint you run — a serverless function, an internal service — receives the same payloads. The ATS does not care what listens; it just delivers reliably.

03Fire-and-forget by design

Webhook delivery runs in the background, detached from the user request that caused it. A slow or briefly unavailable receiver never blocks a recruiter saving a stage change or a candidate submitting an application. Configuration lives in your organisation's settings — set a URL, choose events, and you are live. See what's new for the latest event additions.

Engineering notes

Platform architecture & operations

A1Connection architecture

This app is configuration-based: what you save is acted on directly by the platform — no third-party account link is involved. Settings are validated on save, stored per organisation, and take effect on the next request.

Changes are immediate and reversible; removing the configuration stops the behaviour visibly. As with every connector, secrets (where any exist) are stored encrypted and shown only as presence flags.

A2Write semantics and data flow

Every data movement is an explicit action with a logged result. Writes happen on your click — or automatically only where you enabled a rule (auto-push on hire is off by default, per-provider). Reads — imports of people, accounts, or files — run when you press Import, deduplicate against what you already have (clients by name, people by email), skip rather than overwrite, and report created-versus-skipped honestly, which is why re-running any import is safe by design.

Each action writes a row to the app-activity journal (ats_app_activity): what ran, when, for which record, and the outcome — including the vendor's own error text verbatim when something fails. Usage reporting inside the ATS aggregates that same journal, so integration reporting and integration reality cannot diverge.

Anything that leaves the request path — notification fan-out, webhook delivery, activity journalling, mail — runs in fire-and-forget background threads. A slow external endpoint can never make the interface hang, and a failed side effect is logged rather than silently retried into inconsistency.

A3Operational considerations

Connections are organisation-level and gated to owner and admin roles; recruiters use the features a connection powers but cannot connect, disconnect, or reconfigure. Disconnecting removes stored credentials immediately and stops the dependent features visibly, not silently. Data already imported stays yours and editable.

Imported people arrive marked as imported with conservative privacy defaults — no consent is assumed for anyone who never filled in your application form, and retention defaults apply. Everything written is yours to take: CSV exports and the Data Export app cover the same stores the product itself reads. The exit is as open as the entrance — by design, not concession.

A4Placement in the integration topology

This integration is live in the registry today. One connection per provider unlocks every feature it powers, and the topology grid below shows the neighbouring connectors in the same capability area — statuses come from the same registry that drives the in-app hub, so this page can never claim more than the product does. For anything the catalogue does not cover, Webhooks and Zapier are the generic, documented escape hatch.

Dependency map

Connection typeconfiguration-based (no third-party account)

Secrets at restencrypted; UI shows presence flags, never values

Action journalats_app_activity — one row per action, vendor errors verbatim

Auto-push rulesoff by default, per-provider, every run logged

Registry statuslive

Interface blueprint

Structural schematic of the surface — panels, hierarchy, and interaction affordances. A contract, not a screenshot.

Connection card

● connected — presence flag

scopes: minimum required disconnect

Actions

push — explicit clickimport — deduplicated

Activity journal

Fig. 1 — Webhooks: structural interface schematic. Panels and states are the contract; data shown is placeholder.

Interaction flow — states, validations, feedback

Every state below is enforced server-side; the interface reports it, it doesn't decide it.

Open app pageowner/admin only for changes

Save settingsvalidated on save (format, live checks where possible)

In effectnext request uses the new configuration

Journalactions logged to app activity

Invalid value → named validation error; nothing partial is savedRemoved configuration → behaviour stops visiblySecrets → presence flags only, never re-displayed

Fig. 2 — interaction flow: navy = states, gold = server-enforced gates, green = confirmed outcomes; tags list the edge cases and their feedback.

Event catalogue (from the live registry)

Configured per organisation on the in-app Webhooks page — up to 10 endpoints

EVENT job.publishedA job goes live

EVENT application.receivedA new application arrives

EVENT application.stage_changedA candidate moves pipeline stage

EVENT assessment.submittedA candidate submits an assessment

EVENT video_interview.submittedA candidate finishes a video interview

EVENT video_interview.reviewedA video interview is scored by your team

EVENT placement.confirmedAn offer is accepted — hire confirmed

POST https://your-endpoint.example/hook
Content-Type: application/json

{"event": "application.received",
 "org": "acme-recruiting",
 "data": {"job_title": "Senior Backend Engineer", ...}}

Delivery is fire-and-forget from background threads — your endpoint's latency never blocks the ATS. Payload abridged for illustration.

Neighbouring connectors — Automation & Webhooks

Webhooksthis page Zapierlive

Statuses come from the live registry — browse the full catalogue →

Frequently asked questions

Which events can trigger a webhook?⌄

Core hiring events — job published, application received, and candidate stage changed — each delivered as a structured JSON POST to your configured URL at the moment it happens.

Do webhooks work with Zapier, n8n, and Make?⌄

Yes. Those platforms are built around receiving webhooks — paste their trigger URL into your ATS webhook settings and your hiring events become triggers for thousands of downstream apps.

Will a slow endpoint slow down my ATS?⌄

No. Deliveries are fired asynchronously in the background, so recruiters and candidates never wait on your receiving system, however slow it is.

Is there a per-event or automation-tier charge?⌄

No. Webhooks are included in the subscription with no event metering — a deliberate contrast with tools that sell automation back to you as an add-on.

At a glance

Real-time JSON POST on key hiring events
Job published, application received, stage changed
Works with Zapier, n8n, Make, or any HTTPS endpoint
Asynchronous delivery never blocks users
No per-event fees or automation tiers
Configured per organisation in minutes

See webhooks on your own hiring.

Bring a real job description to a 30-minute demo — free trial included.

Book a demo