Integrations
What it connects to, and which way the data goes.
One roof does not mean leaving the system your offers and compliance run through. Roles, candidates, and the interviews and scorecards already there come in from your ATS — any of five, read the same way; calendars are read and never written to; mail goes from your domain. Nothing is written back to the ATS yet, and that is said here rather than found out later.
macOS app, Windows next · free for ten interviews a month, no card
Your ATS keeps the req
Per vendor, what comes in. These words are kept beside the code that does the reading and printed here from it, so the table can only be wrong if the code is. Three of the five need nothing but your careers-page name for roles; everything past roles needs a credential your admin pastes once. Importing is on the Business plan.
| ATS | Roles | Loop | Candidates | Résumés | Interviews | Scorecards | Panel |
|---|---|---|---|---|---|---|---|
| Greenhouse | careers-page name, no key | the job's own stages, with the credential | Harvest v3: id:secret from your admin | yes | yes | yes | yes |
| Lever | careers-page name, no key | the account's pipeline stages, the same for every posting, with the key | one API key | yes | yes, in the stage Lever booked them | yes: the form's overall recommendation, its rated fields, and its notes | yes |
| Ashby | one API key | the job's interview plan | the same key | yes | yes | yes | yes |
| Workable | your address and one API key, pasted as subdomain:token | the job's pipeline stages | the same key | yes | upcoming events, in the candidate's current stage; past events are listed as unplaced, since Workable does not say which stage they were in | a rating and its note, in the stage it was written; no per-criterion marks, Workable does not expose them | yes |
| SmartRecruiters | company name, no key | the job's hiring process sub-statuses, with the key; inferred from the title when the process has none | one API key | yes, through the attachments API | yes, one per timeslot, filed by the slot's title | a review's overall rating and comment, kept as a label: the scale is not documented and there are no per-criterion marks | yes |
Loop: the rounds a role interviews through, matched to your presets by name. Panel: the people who have interviewed or scored in the ATS, placed on the roles they sat, matched to your team by email. All five read the same seven things through one model, read-only: nothing is written back. Workable is pasted as one value, subdomain and token together; Greenhouse Harvest v3 wants id:secret from your admin. A Workable or SmartRecruiters scorecard arrives as a rating and a note, not marks per criterion, because neither vendor exposes them.
ClearCompany is next. Its credential is generated in your own ClearCompany settings, not issued by us.
Which way the data flows
Named up front because finding out after you have signed up is worse than reading it now.
- In · roles and loops
- Open roles, on demand. Each arrives with its interview loop — the ordered rounds it runs — matched to your presets by name, so you are not retyping five rounds you already described somewhere else. Where the ATS has no plan for a job, a loop is inferred from the title and marked as a guess.
- In · candidates
- Name, email, LinkedIn, the stage they are at and where they came from, filed under the right role. Résumés come too, behind a switch you can turn off. From all five: the interviews already scheduled, who sat them, and the scorecards already written — against the interview they were written for where the ATS names one, otherwise on the stage. How much each vendor hands over is in the table above.
- Out · nothing, yet
- Interview outcomes and scorecards are not written back to your ATS. Your ATS stays the system of record, and what is decided here is carried across by hand. When that changes it will be said here first.
What we keep from what we read
The question a security review asks about an ATS connection is not whether the key is safe — it is what you took. Here is the whole answer.
- Four fields from a job
- An ATS returns dozens of fields per posting. We keep an id, a title, a location and a URL.
- People only when you import them
- No candidate row exists here until you choose to bring them in, and the résumé comes only while the switch is on.
- Nothing dropped silently
- A stage that matches no round, a scorecard attribute that matches no criterion, a person who cannot be placed — each is listed in the import’s report with the reason, not discarded. A field we have no home for is counted, not lost.
- Importing again updates
- A role, a candidate or an interview already here is updated in place by the ATS’s own id rather than duplicated.
One key, pasted once
The credential is sealed before it reaches the database — AES-256-GCM, a fresh nonce for every value, the key held in the platform’s secret store and never in the application — and is never shown again. It does not appear in a log; only a fingerprint does, enough to find the row and useless to anyone else. A key that stops working because your admin rotated it degrades to “needs your API key”, and nothing already imported is lost. For Greenhouse the credential is a Harvest v3 client id and secret, pasted as one value: id:secret; for Workable, the account subdomain and the token, as subdomain:token. How every credential is held is on the security page.
Where this has been tried: against a mock server that stands in for all five vendors, built from their own published API references, with real paging and a real 401 for a wrong key. No adapter has run against a real customer key yet. If yours is the first, the import’s report will say exactly what it placed and what it could not, and we would rather you read that than a promise.
What else connects
The calendars people already keep, the address the candidate already trusts, and the model the team already has.
- Google Calendar
- Each interviewer connects their own. Busy times are read to find open slots, in their own zone; nothing is written to the calendar, though the Google consent screen shows a write scope we do not use. Each connection chooses whether we may read event titles or only the blocked time. The booking goes out in the invitation as a calendar file, which any calendar accepts.
- Microsoft 365
- Each interviewer signs in with their work or personal Microsoft account. We ask for read-only calendar access and the consent screen shows nothing more. Busy times come from the account’s schedule; titles only when that person chooses. Not yet proven against a real tenant.
- Calendly
- For panelists who live in it. Paste their scheduling link; it stays a per-person connection because Calendly is personal by design.
- Working hours
- For anyone with no calendar at all — set the hours they actually work and they stop being treated as free at 3am. Nobody has to connect anything to be booked.
- Your sending domain
- Every message the loop sends — invitations, calendar files, advances, rejections, reminders — goes from your own domain once your IT adds the records. Until they are in, it sends from ours with replies coming to you, and the app says which.
- The assistant: theirs, or ours
- In the app, the assistant runs on an agent already on the machine or on ours, included in the plan; chosen once, in the app. In the room, the interviewer’s assistant is their own, and the candidate’s is always their own.
See your own loop run before you decide anything.
Ten interviews a month, free. Add a role by hand and book one interview on it. Importing from your ATS comes with the Business plan.