What is never exposed
The data the API never returns, whatever a key is allowed to read.
Some data has no place in the Tahoe API at all. It is not behind a scope, it is not available to a special key, and a support request will not unlock it. Read this page before you design a schema that expects any of it.
Where the API would otherwise have a field for such data, the field is named in restricted with the reason never_exposed:consent_scope. That way you can tell “Tahoe will not give you this” apart from “this is empty”. See Withheld fields.
What the API never returns
| Data | Why |
|---|---|
| Equal-opportunity (EEO) and diversity answers | Candidates gave them for aggregate reporting and nothing else. They are not returned per candidate, and not in aggregate either: a small enough group makes a total identify a person. |
| The content of a phone screen: answers, transcripts and recordings | The notice the candidate heard before the call covered Tahoe screening them, not passing the call on to anyone else. screening:metadata:read tells you that a screening happened and how it went. The content stays in Tahoe. |
| The LinkedIn profile capture | You get has_linkedin_capture: true and nothing more. The captured profile is held on terms that do not allow passing it on. |
| Links and tokens that act as the candidate, such as application status links, screening links and file storage keys | Each one lets its holder act as that person. No scope should be able to hand that to a third party. |
| Account secrets and permission settings | Which accounts hold wide access is exactly what an attacker wants to know first. |
| Search prompts and saved searches | A customer's hiring plans, written out in plain words. Who they are looking for, and how, is more sensitive than the list of candidates it produced. |
| Billing, credits, invoices and payment records | A customer's spending is their own business. |
| Recruiter notes and scorecards | The API returns rejection reasons, the AI score rationale and stage history under applications:internal:read, and nothing else a recruiter wrote about a candidate. Free-text notes are written by people who did not expect the candidate to read them. |
| Another workspace's data, ever | Every request is limited to the workspaces your key was granted. An ID from any other workspace returns 404, the same as an ID that does not exist. |
Phone screens: whether, never what
The screening endpoint shows the pattern. You learn that a call happened, how long it lasted and how complete it was. The answers, the transcript and the audio are named as withheld, and no scope changes that.
curl -s https://tahoe.workonward.com/api/partner/v1/applications/app_6Qm2xKd4Rp8v/screening \
-H "Authorization: Bearer $TAHOE_API_KEY"{
"object": "screening",
"application_id": "app_6Qm2xKd4Rp8v",
"has_screening": true,
"call_status": "completed",
"completion_state": "complete",
"duration_sec": 412,
"consent_state": "granted",
"ambiguous_caller": false,
"started_at": "2026-09-14T15:02:41.118Z",
"ended_at": "2026-09-14T15:09:33.640Z",
"restricted": ["responses", "transcript", "audio"],
"restricted_reason": {
"responses": "never_exposed:consent_scope",
"transcript": "never_exposed:consent_scope",
"audio": "never_exposed:consent_scope"
}
}The API does not run searches
Running a candidate search in Tahoe spends the workspace’s credits and brings in new profiles. An integration bug should never be able to spend a customer’s money, so the API has no way to start a search. It does not reveal new contact details either: the contact endpoints return only what the workspace has already revealed in Tahoe.
POST /pool/search is the free alternative. It searches the shared pool of profiles Tahoe already holds, with the same kind of query, and spends nothing.
The resume window is mirrored
Resumes from job applications follow the same rules in the API as in the product. A resume is free to view and download for 90 days after the application. From day 90 to day 120 it can be viewed but the file cannot be downloaded. After day 120 it is locked until the workspace unlocks it in Tahoe, which costs 50 credits, once, and is permanent. If the workspace has not unlocked a resume, neither has your integration: the resume endpoints return 403 resume_locked with the state and the unlock cost.
Each resume carries a block that tells you where it stands and when that changes:
{
"resume_access": {
"state": "view_only",
"free_until": "2026-12-03T14:20:05.000Z",
"view_until": "2027-01-02T14:20:05.000Z",
"state_changes_at": "2027-01-02T14:20:05.000Z",
"unlock_credits": 50,
"can_view": true,
"can_download": false
}
}Because the window moves with time, a resume can go from readable to locked without anything changing on your side. Do not treat a successful read as a lasting right: check state_changes_at and read again rather than keeping a copy indefinitely.
Data you can read still comes with rules
Being able to read something is not permission to pass it on. Contact details belong to people who never signed up with you. Wherever a response includes a licence block, licence.redistributable is always false.
- Do not build a public directory or a resale list out of anything you read here.
- Honour erasure notices. An erasure notice is an instruction to delete your copy of a person’s data by a deadline. The notices need only
events:read, so a narrow key never stops you from hearing them. - Do not re-identify people. Joining aggregate numbers against your own data to work out who an individual is defeats the reason they were aggregated.