List the roles (offers) in Recruitee/Tellent with their ids, status and candidate counts. Start here — every other tool is keyed on an offer id.

The pipeline stages of one offer, with their ids. Needed before writing an evaluation, because an evaluation is filed against a stage.

Everyone on ONE offer, with their stage, disqualification state and ratings — genuinely scoped to that offer rather than the whole company database.

Full record for one candidate: contact details, tags, every placement with its stage, and their application answers. Salary answers live in groupedOpenQuestionAnswers and are PER OFFER — read the offer id on each, because someone who applied to several roles carries several answers and the flat list cannot tell them apart.

Find candidates by name or keyword across the company.

SEARCH THE WHOLE CANDIDATE DATABASE — every person who ever applied or was added, not just one role. This is the sourcing tool: use it to find people already in the ATS before going out to LinkedIn, because someone who applied to a similar role last year is the cheapest good candidate there is.

IT SEARCHES CV TEXT, not just names and titles. query takes boolean operators exactly as the Recruitee search bar does: "renewals AND churn", "(SaaS OR B2B) AND expansion". Every result carries whyMatched — the actual sentences that matched — so a coincidental hit can be dismissed without opening the profile.

SEARCH FOR THE EVIDENCE, NOT THE JOB TITLE. Titles are inconsistent between companies; what someone DID is written in their CV. Prefer "quota AND renewals" over "Account Manager", and run several narrow searches rather than one broad one.

MOST OF THIS DATABASE WAS REJECTED ONCE. Every result lists each role the person sits on with its stage and, where they were turned down, the reason. Read it before you suggest anybody: "wrong location" two years ago may not apply now, "failed the assessment" still does. Never present someone as a fresh find without saying they have been through the process before, and for which role.

excludeOffer keeps people already on a role out of the results, which is what you want when topping one up. Combine filters freely — they AND together.

The rating scale this company is configured for. Read it BEFORE writing an evaluation: the valid rating values differ per tenant (a 4-point thumbs scale has no "neutral", a 5-point one does), and guessing files the wrong verdict on a real person.

Every evaluation on a candidate: rating, note, stage, reviewer and date, flattened into one list, newest last.

READ THIS BEFORE WRITING ONE, so you build on what other interviewers recorded instead of duplicating it.

IF YOU ARE COPYING THESE SOMEWHERE ELSE, carry the evaluation id across so a second sync updates the same row instead of duplicating it.

ATTRIBUTION IS UNRELIABLE COMING BACK. Recruitee files everything written through an API token under the token owner, so reviewer may be the token holder rather than whoever ran the interview. The note usually names the real one. Do not present the reviewer as fact when the note disagrees with it.

Notes already on a candidate, newest first.

Create a candidate in Recruitee/Tellent AND place them on a role, in one call. Works entirely from what you are told here — nothing has to exist anywhere else first.

WHAT YOU NEED. Required: the role (its title is enough, e.g. "VP of Customer Success") and the person's full name. Strongly recommended, because a record without them is close to useless to a recruiter: email, and either a LinkedIn URL or a CV file. Optional: phone, tags, a coverLetter block for their background and why they are worth a look, and where they came from. If the user has not given you the recommended fields, ASK for them before creating — the preview call lists exactly what is missing.

TWO-CALL GATE, ALWAYS. The first call (confirm omitted or false) returns what would be created, what is missing, and any existing candidates with the same name — and writes nothing. Show that to the user. Only call again with confirm true once they have approved THIS person for THIS role. One person per confirmation.

THIS CREATES A REAL RECORD FOR A REAL PERSON, visible to the whole hiring team and counted in reporting. The preview always runs a duplicate check; if it finds a match, resolve that with the user rather than creating a second record that splits their history.

DO NOT INVENT DETAILS. An empty field beats a guessed one.

STAGE. Defaults to "Sourced", which is right for anyone we went looking for. Pass stage: "Applied" only for someone who genuinely applied. Recruitee's create endpoint has no stage parameter, so this moves them immediately after creation and tells you if that did not take.

Write an evaluation (a thumbs rating plus a note) onto a candidate for one role — the "Evaluation" tab of their profile.

WORKS BY NAME. Give the person's name and the role title and the text; ids are not needed. If a name matches more than one candidate it refuses and lists them rather than guessing — filing a verdict on the wrong person is the failure that matters here.

THE STAGE IS AUTOMATIC. It files against wherever the candidate actually sits on that role, which is what an evaluation means. Only pass stage to override that deliberately.

TWO-CALL GATE, ALWAYS. First call previews, second call with confirm true writes.

IT IS FILED IN THE TOKEN OWNER'S NAME. Confirmed in practice: it appears in Tellent as "You evaluated", indistinguishable from one clicked by hand. So never write one as though it were another interviewer's verdict, and never write one for a conversation the token owner did not have or has not read. If the judgement came from someone else, say so in the note.

CALL rt_get_rating_scale IF UNSURE. Valid ratings depend on the configured scale. This company is on a 4-point thumbs scale: strong_no, no, yes, strong_yes ("yes" scores 4/5, 75%). A value the scale does not have is rejected rather than rounded.

PUT THE REASONING IN ratingNote. A bare rating nobody can audit is not worth writing. Where the verdict came from a screen or interview, say which.

Structured questionnaire scorecards (per-question answers) are NOT supported — only the rating card. If a role uses a questionnaire template, say so rather than flattening a multi-question scorecard into a single rating.

Move an existing candidate into another pipeline stage on ONE of their roles — to advance them, or to mirror a move already made wherever your pipeline is tracked. Scoped to an offer because a candidate can sit on several pipelines at once.

Call rt_get_stages first if you do not know the offer's stage names; an unknown name is refused and the real ones are listed back. If you are mirroring a move from another system, do not assume the two name stages the same way — ask which stage is meant rather than picking the nearest word.

THIS IS NOT A REJECTION TOOL. It cannot disqualify anyone, and it refuses to move a candidate who has already been disqualified, because that would requalify them. Only move somebody because a person moved them or told you to — never because a meeting was booked, a score looked good, or the pipeline seemed stale.

Two-call gate: preview, then confirm. The move is verified by re-reading the candidate afterwards; if it did not land, that is reported rather than claimed as done.

Attach a local file to an existing candidate — a CV, or a summary document. Set asCv to make it their CV rather than a plain attachment; a record with no CV shows "No CV or resume yet" in Tellent.

Setting a file as the CV REPLACES any CV already on file, demoting theirs to a plain attachment — so that is refused unless you pass replaceCv.

Only ever attach a file the user named. Never go looking for one, and never substitute a different file if the named one is missing. Two-call gate: preview, then confirm.

The upload is verified against the candidate afterwards; if it comes back unlinked, say so rather than reporting it as attached.

Add a note to a candidate. Use for context that is not a verdict — an assessment summary, sourcing rationale, or a call recap. Accepts a name or an id. Two-call gate.

Visibility "public" means anyone with access to the candidate can read it, which is usually what you want for a shared hiring record.