INTEGRATIONS · EXPERTINI ATS

How Connectors Work

One page of truth about how Expertini connects to your other systems: one connection unlocks every feature it powers, your credentials stay yours, and every action is a button you pressed — never a sync you didn't ask for.

3 min read · Updated July 2026 · Expertini Editorial

Every ATS claims integrations. This page explains how Expertini's actually work, because the mechanics are the product: what you authorise, what we store, what moves in each direction, and how you turn any of it off. The short version — one connection per provider unlocks everything that provider powers (connect Google once and Sign-In, Calendar, Meet, Drive backup, and Sheets exports all light up); credentials are either your own sign-in on the vendor's site or keys you generate in your own account; and every data movement is an explicit action with a logged result, visible on each app's activity page.

The deeper principle is that connecting should compound what the ATS already does natively. Your CRM's contacts don't just get copied — they land in an own candidate database with CV parsing, full-text search, and resume scoring attached, so imported data becomes working data. Your ERP's customer list becomes a live Client CRM with commission tracking. Files dropped in your cloud storage become parsed, deduplicated candidate records. The connector is the pipe; the value is what the platform does with what flows through it.

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

01Two kinds of connection, both honest

Account connections use the vendor's own sign-in: you click Connect, approve on Google's, Microsoft's, Salesforce's, or Zoho's own consent screen — which lists exactly the permissions requested, always the minimum the features need — and can revoke from either side at any time. Direct connections are for systems you host or key yourself: ServiceNow, Zendesk, SAP Sales Cloud, Odoo, ERPNext, S/4HANA, Slack, WhatsApp Business, SendGrid, custom SMTP, and webhooks take your instance URL and credentials, verify them live before saving anything, and store secrets encrypted at rest. Nothing on the Connectors page shows a Connect button for something that can't actually connect — vendors that need a partner agreement say so on an honest card instead.

02What moves, and who decides

Writes: hires push to your HRIS or CRM on your click, or automatically only if you enable the auto-push rule — off by default, per-provider, logged per action. Reads: imports from CRM accounts, CRM contacts, HRIS people directories, ERP customers, and cloud CV folders run when you press Import, report created-versus-skipped honestly, deduplicate against what you already have, and never overwrite existing records. There is no background synchronisation you didn't configure, no bulk copy you didn't trigger, and re-running any import is always safe.

03What we store, and what we never do

Connections store tokens and keys encrypted; secrets are never rendered back to any screen — pages show presence ("connected", "saved ✓"), not values. Imported people arrive marked as imported, fully editable, with conservative privacy defaults: no consent is assumed for anyone who never filled in your application form, and retention defaults apply. Disconnecting removes stored credentials immediately, and the Data Export app means everything the platform holds is downloadable by you at any time — the exit is as open as the entrance.

04Where to see it all

The in-app Connectors page is the single control panel: every account and direct connection with live status, connect and disconnect, and links to each app's own page — where its actions, configuration, and a real activity log live. Records show their integration history too: a candidate or client's page lists every push and import that touched it, with failures shown in red and a fix link, because an integration you can't audit is an integration you can't trust.

Engineering notes

Platform architecture & operations

A1Connection architecture

The connection model for this integration is stated honestly on its card: where a public API exists it is used with your own account and consent, and where a vendor requires a partner agreement the page says so instead of showing a Connect button that cannot work.

Once available, credentials follow the platform standard: encrypted at rest, presence-flag display, immediate removal on disconnect.

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 typestated per-vendor on the card

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 — How Connectors Work: 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.

Connectowner/admin clicks Connect on the Connectors page

Vendor consentthe vendor's own screen lists the exact scopes

Token exchangeserver-side callback; secrets never touch the browser

Connectedencrypted store; card flips with presence flag

Explicit actionspush / import / schedule — each one journalled

Consent denied → the vendor's error code surfaces in a toast, namedPlatform keys missing → honest setup pointer, not a silent bounceToken expired → automatic refresh at the chokepointRefresh rejected → visible reconnect prompt, features never break silentlyPlan below minimum → lock card names the exact plan

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

Frequently asked questions

Do I need IT to set this up?⌄

Usually not. Account connections are a sign-in and a consent click. Direct connections need whatever your own system's admin would need anyway — an API key from Odoo, a token from Zendesk — pasted once into a form that verifies it live.

Can one team member connect for the whole organisation?⌄

Connections are organisation-level and managed by owners and admins. Recruiters use the features; only privileged roles can connect, disconnect, or change what's linked.

What happens when I disconnect?⌄

Stored credentials are removed immediately and the features that connection powered stop — visibly, not silently. Data already imported stays yours and editable; nothing keeps flowing.

Are imports going to duplicate or overwrite my records?⌄

No. Every import deduplicates — clients by name, people by email — and skips rather than overwrites. Each run reports exactly what it created and what it skipped, so re-running is safe by design.

Is any of this an extra charge?⌄

No. Connectors are part of the subscription — see pricing. Your accounts with the connected vendors remain your own contracts.

At a glance

One connection per provider unlocks every feature it powers
Vendor-side consent screens; minimum scopes; revoke from either side
Direct connections verified live, secrets encrypted, never re-displayed
Imports are explicit, deduplicated, re-runnable, and logged
Auto-push rules are off by default and per-provider
Imported contacts become parsed, searchable, scoreable candidates
Full data export always available — no lock-in by design

See how connectors work on your own hiring.

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

Book a demo