How candidate records get in, and what stays where it is
Candidate feedback only works if the platform knows who applied, for which role, and when they start. This is how records reach CultureMonkey from your existing stack, and what is deliberately left in your ATS, inside the wider candidate experience platform.
Book a free, no-obligation product demo call with our experts.
One endpoint, and the fields that matter
Candidate records are posted to a JSON endpoint. What comes with each record is what makes the rest of the program work: the requisition it belongs to, who was recruiting it, who the hiring manager was, and when the person is due to start. Those four are what every cut in the recruitment dashboard is later built from.
Or a spreadsheet, if you would rather not wait on engineering
Not every recruiting team can get an API integration prioritised, and a pilot should not have to. Candidate records import from CSV as well, through a screen rather than a ticket, and the two routes populate exactly the same fields. Jobs import the same way, matching on external ID and linking to locations as they go.
What actually happens to connect it
The module is switched on
The candidate module is enabled for your account by our team. It is not a self-serve toggle.You send candidate records
Your ATS or HRIS posts to the endpoint, directly or through whatever middleware you already run. Or you upload a CSV and skip the integration work entirely.Stage conditions are configured
We set the rules that decide which lifecycle stage a candidate is in, based on the fields you send. Several fields can be combined in one condition.Surveys start running
From then on each stage issues its own survey as candidates reach it, with no further work from your recruiting team.
Your ATS stays the system of record
Worth being direct about, because the word integration is often used to mean something two-way. Nothing here writes back into your applicant tracking system, and nothing here replaces it. The pipeline, the scheduling and the offer all stay where they are.
Every field you send is a way to cut the results
The point of sending a requisition, a recruiter and a job level is not record-keeping. Each one becomes a filter on the reports, so a weak score has an owner and a location rather than being a company average. Configured under Candidate Settings, with display names and ordering of your choosing.
| Dimension | Comes from | Typical use |
|---|---|---|
| Job family, category, profile, family group | Your job records | Comparing engineering hiring against frontline hiring |
| Primary recruiter, recruiter manager | The candidate record | Giving a weak process score an owner who can change it |
| Hiring manager | The candidate record | Reading the hiring manager feedback survey beside what candidates said |
| Job level L2, L3, L4 | Your level hierarchy | Separating graduate hiring from executive search |
| Custom attributes | Whatever you define | Anything above that your organisation is actually shaped by |
Surveys wait for the sync, not the other way round
A survey that fires before the day's candidate records have landed goes to the wrong list, or to nobody.
The daily job runs after the sync
The hiring manager feedback survey scheduler was moved to early morning UTC specifically so candidate data synced from HRIS systems is already in place when it runs.Joining dates drive the handoff
Date of joining is held on the candidate record, which is what makes the boundary between the last candidate survey and the first employee one a real date rather than an estimate.Requisitions are named, not numbered
The job external ID travels with the candidate and can be dropped into email copy, so a message can name the actual role rather than saying “your recent application”.Jobs are managed in the module
Job positions are created and maintained inside the candidate module, so the candidate experience journey map has something stable to attach stages to.
Fitting the recruiting stack, answered
Which applicant tracking systems do you integrate with?
Rather than a list of named connectors, CultureMonkey takes candidate records through a single JSON API endpoint, which any ATS or HRIS can post to directly or through the middleware most teams already run. That is a deliberate answer rather than an evasive one: a connector list is only as good as its least maintained entry, and a documented endpoint does not go stale when a vendor changes their API. If you want to know whether your specific stack can send to it, that is a five-minute conversation with our team.
Does CultureMonkey write anything back into our ATS?
No. The flow is one way. Candidate records come in, surveys go out to candidates, and the results stay in CultureMonkey. Your applicant tracking system remains the system of record for the pipeline, scheduling and offers, and nothing here modifies it. Teams evaluating this usually want that stated plainly, because a two-way sync is a much larger piece of work to govern.
What data do you need about each candidate?
Enough to reach them and to place them: their identity and contact details, the job requisition they applied to, the primary recruiter and hiring manager, and their date of joining if they get that far. Stage is not something you send as a label. It is worked out from the fields you provide, using conditions configured for your account, so the stages match your process rather than a fixed list of ours. See the candidate experience journey map for how those stages are used.
Do we have to build an API integration to start?
No. Candidate records import from CSV through a screen in the product, which is how most pilots start: no engineering ticket, no waiting for a sprint. The import matches on external ID, so re-uploading updates the records that already exist rather than duplicating them, and any rows that fail come back as their own file with the reason for each, to fix and re-upload. Teams typically move to the API once the program is running and they want it hands-off.
Can we report on fields that are specific to our organisation?
Yes. Alongside the standard set of job family, job category, job profile, job family group, primary recruiter, recruiter manager, hiring manager and job levels L2 to L4, your account can define custom candidate attributes and use those as filters too. They are configured under Candidate Settings with their own display names, ordering and single or multi-select behaviour, and visibility can be set separately for super admins and sub admins. The recruitment dashboard shows how those cuts are read.
How long does it take to set up?
Less than teams expect, and a CSV import needs no engineering time at all. On the API side it is one endpoint, a set of fields, and no ongoing work once records are flowing. What takes the time is agreeing the stage conditions, because that is where your process gets described properly, often for the first time. Enabling the module and configuring those conditions are both done by our team rather than in a settings page.
Do candidates need an account or an app?
No. Candidates have no login and no company inbox, which is the whole reason delivery runs over email, WhatsApp and SMS instead. That is covered on the multilingual candidate surveys page, along with reaching people in a language they can answer in.
See how this would sit beside your ATS
One endpoint, no write-back, and your pipeline left where it is.