Webhooks
POST real-time hiring events to any URL — the raw material Zapier, n8n, and Make are built on.
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.
本頁內容
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.
平台架構與營運
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.
相依性對應
介面藍圖
互動流程 — 狀態、驗證、意見回饋
Event catalogue (from the live registry)
POST https://your-endpoint.example/hook Content-Type: application/json {"event": "application.received", "org": "acme-recruiting", "data": {"job_title": "Senior Backend Engineer", ...}}
常見問題
Which events can trigger a webhook?⌄
Do webhooks work with Zapier, n8n, and Make?⌄
Will a slow endpoint slow down my ATS?⌄
Is there a per-event or automation-tier charge?⌄
一目了然
- 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