Don't switch ATS. Plug Aya into the one you have.
Aya's interview becomes one stage of the process you already run. The candidate talks on WhatsApp, and the score — with the evidence behind it — lands on the record your team already looks at. Nobody opens a second screen.
API keys, the test environment and webhooks are all self-service in your account settings. There is no waiting list and no implementation project to get started.
This is what plug-and-play means, in three sentences
No migration, no new tool for the team to learn, no report to assemble by hand.
Your ATS still owns the process
Roles, pipeline and history stay where they are. Talpy does not ask you to migrate anything, or ask a recruiter to change the screen they work in every day.
Aya talks to everyone who applied
The interview runs on WhatsApp or through a link, at the candidate's pace: they answer when they can, and nobody books a slot. Screening stops being a queue and becomes a ranked list.
The score comes back with the evidence behind it
Overall score, adherence to the profile, a score per competency and the literal excerpt from the answer that justifies each one. A person decides; the AI recommends and shows why.
Workable: four steps, and the score lands on the candidate's record
It is the only native integration today, and it runs both ways: Workable tells us when a candidate reaches the stage you chose, and Talpy writes the evaluation back onto their record there.
Connect
Your subdomain and an access token generated by an administrator of your Workable. The token is stored encrypted on our side.
Pick the trigger stage
A candidate moved into that stage is imported with the role and the CV, and gets a screening score before the conversation even starts. Leave it blank and every new application comes in.
Aya interviews
The invitation goes out on the candidate's WhatsApp. When the record has no phone number, we write a comment saying so instead of failing silently.
The score returns
A comment on the Workable record with the score, adherence, summary, competencies with their evidence and a link to the full report, plus a thumbs rating. If you want it, an approved candidate also moves stage on their own.
What this integration does not do
- One connection per company and one trigger stage. Two different flows in the same account do not fit yet.
- The thumbs rating has two states: positive from the minimum score you set, negative below it. It ships set to 7.
- The role mirrored into Talpy is created as internal and never reaches Google. The public posting stays the Workable one, which is how it should be.
- A candidate who did not come from Workable is not pushed into it. For that direction there are the API and the webhooks.
- There is no automatic retry on the way back. If Workable is down when the evaluation is ready, the score stays recorded in Talpy and the error shows up on the integration screen.
Signed webhooks: your system finds out immediately
Every candidate event goes out as a POST to the address you register. There are six, and they cover the whole cycle — not just the end: a system that only receives “evaluated” learns about the application hours after it happened.
candidato.criadoSomeone applied — through the role link, the careers page or the API.
candidato.triadoThe CV was read and scored for adherence to the role profile.
entrevista.iniciadaThe candidate replied to the first contact and the conversation with Aya began.
candidato.avaliadoAya finished the interview and recorded the evaluation: score, competencies and evidence.
candidato.decididoA recruiter approved or rejected the candidate — the human decision, on the record.
revisao.solicitadaThe candidate asked for a human review of the evaluation. Worth treating as a priority.
Signed, so you can trust it
Every POST carries an HMAC-SHA256 of the body, computed with a secret unique to your endpoint. Checking that signature is what stops someone from impersonating Talpy and injecting an approved candidate into your system.
X-Talpy-Signature: sha256=…
Test before you depend on it
A button in the panel fires a signed test event and shows you the HTTP status your server returned, next to the time of the last real delivery.
What does not exist
Automatic redelivery. An endpoint that does not answer within five seconds loses that event; the status is recorded on screen, and the way to recover what you missed is the API.
API v1: for teams that would rather write the flow
REST over JSON, authenticated by key and versioned in the path. The endpoints cover roles, candidates, CVs, the WhatsApp invitation and the interview with its transcript and evaluation.
/api/v1/jobsjobs:read/api/v1/jobs/{id}jobs:read/api/v1/jobsjobs:write/api/v1/jobs/{id}jobs:write/api/v1/jobs/{id}/candidatescandidates:read/api/v1/candidatescandidates:write/api/v1/candidates/{id}candidates:read/api/v1/candidates/{id}/whatsappwhatsapp:send/api/v1/interviews/{id}interviews:read/api/mcpmcp:read7 permissions, ticked one at a time
A key is created with only what you tick, and the permissions are split by ACTION because the damage each one can do is different: reading a role is effectively public, creating a candidate touches personal data, and sending WhatsApp costs money and risks the reputation of the company's number.
jobs:read- Read the company's jobs and the details of each one.
jobs:write- Create jobs and change existing ones.
candidates:read- Read the candidates on a job and a single candidate's record.
candidates:write- Create candidates, including with a base64 CV.
interviews:read- Read the interview and the candidate's evaluation alongside the record.
whatsapp:send- Send a WhatsApp message to a candidate.
mcp:read- Query Talpy from an AI agent using the MCP protocol.
The key is shown once
We store the hash, not the key — not even we can recover it later. Lose it and you revoke it and generate another, and the prefix of the value says out loud, inside the secret itself, whether it is live or test.
Limit and environment on every response
120 requests per minute per key. Every response tells you how much of the limit is left and which environment produced it — so you never discover the ceiling by hitting it, and never swear you pointed at production while reading toy data.
A copy of your company, staffed by people who do not exist
A test key works against a mirror organisation of yours, created on demand and already seeded with one role, two candidates at different stages and one evaluation to read.
Same routes, same errors
It is not a simulator returning canned answers: it is the same code and the same database, only with toy data. A fake response lies about the shape and about the errors, and you find the difference in production.
Nothing leaves the building
No WhatsApp, no billing, and no consumption of your plan. The example candidates have no phone number, so there is nowhere to send a message.
You can reset it
Made a mess of the sandbox while testing? One command wipes and reseeds it, and your real operation feels nothing.
Ask through the assistant your team already uses
Talpy exposes an MCP server: your company's AI client points at the address, sends the key, and the team asks in plain language — “who did best on the support role?”. It exists because the people who buy recruiting software are HR, not engineering: an API assumes someone who writes code, reads documentation and handles errors.
Five queries, and nothing but queries
listar_vagas- The company's roles, with their status and how many candidates each one has.
detalhar_vaga- One role with the competencies Aya evaluates and the weight of each — those are the criteria the scores are built from.
listar_candidatos- The candidates on a role with score, adherence and stage, highest first.
detalhar_candidato- A candidate's full evaluation: score per competency, the evidence behind each score, points of attention, highlights and the human decision if there is one.
resumo_do_recrutamento- The company's overall numbers: open roles, candidates, completed interviews, average score and plan usage. Contains no personal data at all.
Three locks, and not one of them is decorative
- Its own permission. Assistant access is a separate scope from the read scopes. An integration key that already read candidates does not get this channel thrown in.
- The company's consent. It ships switched off. The account administrator is the one who turns it on — not us, and not whoever generated the key: it is the company that decides whether its candidates' data may be read by a model inside the AI client it chose.
- An audit entry per query. Every call is written to the company's audit trail, along with what was asked. Access to candidate data that leaves no trace is the access you cannot explain afterwards.
Read-only, and no contact details
No tool writes, decides, deletes or sends a message — a model interpreting “let everyone know the role is closed” must not be able to spend money. And none of them returns a phone number, an e-mail or a CV: to reach the person, someone opens the record in the panel, where access is by name and lands in the audit trail.
Zapier, Make, n8n, a spreadsheet, your team chat
This works through the webhook — and here is the honest part: we do not have a published app in the Zapier or Make directories. What does exist is simpler than it sounds: every one of those tools accepts a webhook trigger, and that is where you paste the address Talpy gives you.
From there, an evaluated candidate becomes a spreadsheet row, a card on your board, a message in your team chat or a candidate created in your ATS. The ready-made recipe is in the documentation, next to the shape of the payload that arrives.
What does not exist yet
This page promises only what is in the product today. What is missing is missing — and finding that out in a meeting costs everybody's time.
- A published app in the Zapier, Make or n8n directories. The connection is a webhook, and you are the one who makes it.
- Native integration with Gupy, Greenhouse, Lever, SAP or Workday. Those come in through the API and the webhooks, not through a button.
- Automatic redelivery of a webhook that failed.
- Writing through the AI assistant. The MCP channel is read-only on purpose, and that is not queued to change.
- Two-way sync outside Workable. In any other ATS, your code decides what goes up and when.
What people ask before integrating
Do we need a developer to get started?
For Workable, no: the connection is made on a screen, with a token from your own Workable. For webhooks, someone needs an address that receives a POST — which an automation tool solves without code. The API is the path for teams that want to write the flow themselves.
What does the integration cost?
Nothing on top. The API, the webhooks, the test environment and the AI-assistant channel are part of the product; what is billed is interviews. Each plan's limits are on the pricing page.
Can we test without touching a real candidate?
Yes, and it is the recommended path. A test key works against a seeded copy of your company where nothing leaves the building — no WhatsApp, no billing. Once it works there, swap the key.
What is the usage limit?
120 requests per minute per key, and every response tells you how much is left. If your case needs more, talk to us before you build around the ceiling.
Tell us which ATS you use
Name the system, your hiring volume and where in the process Aya should sit. We reply with the concrete path — and when there is no path, we say that too.
We use this data only to reply to you. Details in the Privacy Policy.