Aptora

Fetch one job listing including the full job spec, its `required_skills` (with the `skill_id` list_jobs filters by) and the application contact (contact_email/contact_person) when the listing carries one. For one listing the user singled out: a list_jobs result already opens each of its rows in place, so fetching a page row by row stacks up one card per job and says nothing the list did not. Listings of other workspaces are subject to a fair-use read budget of distinct listings per hour and day; re-reading one is free, and a refusal carries `retry_after` in seconds. Fair use is what the terms of service set out in § 17.

get_job

The field schema for creating/updating a job listing. Static — call it before the first write instead of guessing field names.

get_job_schema

Status and a page of results for a run started by search_candidates. 'status' is the search itself; 'refine_status' is the optional AI fit estimate and is null until refine_search is called. Results are complete and ranked either way — a failed estimate leaves them untouched. Paging costs no allowance.

get_search

What this server can store: the supported AptoraCV sections, the section/field aliases it accepts, the allowed enum values and the supported import features (strict, merge, normalization). Call this before importing a resume from another format.

get_capabilities

List all of the signed-in user's CVs (id, name, theme).

list_cvs

List the workspace's job applications, newest first, each with its composed application email — null for one delivered into a team workspace, whose `status` says where it stands instead. Readable in every workspace; whether NEW ones may be made is apply_to_job's question (a personal workspace or a consultancy team, never a company/agency team).

list_applications

List job listings from the Aptora job board that require at least one of the given skills, the listings requiring most of them first and the newer one within an equal count. `skills` is mandatory and needs at least 3 skill ids: the board is searched, never listed whole. Skill ids come from get_cv (`profile_skills`) or from any listing's `required_skills`; an id that names no active skill is refused by name. Every summary carries the listing's `required_skills`, so one call answers which listings fit and why: the result is a board the user pages and opens each listing in, so do not walk the rows with get_job. A bare skill search is served up to page 10; further pages need a narrowing filter (type, title, company or location). Pages and listings of other workspaces are subject to a fair-use read budget: a refusal carries `retry_after` in seconds. Fair use is what the terms of service set out in § 17.

list_jobs

This workspace's candidate searches, newest first, one page at a time.

list_searches

The workspace shortlist, optionally filtered by job, one page at a time.

list_shortlist

The listings this workspace owns, including expired ones. Different from list_jobs, which is the public board.

list_team_jobs

Put one of this workspace's listings on the public board and into candidate matching. Reversible with unpublish_job — the listing keeps its id, its skills and its match history either way.

publish_job

Drop one entry from the workspace shortlist.

remove_from_shortlist

Find candidates for a job (job_id) or for free criteria (filters) across every profile whose owner opted into being found. Ranks them by skill overlap and job-title fit and returns the evidence behind each score. Every search needs an anchor: a job_id (one of this workspace's listings, whose detected skills are the requirements) or at least 3 ids of active skills in the filters — those are what a candidate is ranked against. Every filter EXCLUDES on top of that: skills, titles, country, remote share and day rate each narrow the set, and no score buys a candidate back in. Within one list any entry counts, across lists all of them must. Skill ids come from a listing's required skills or a search result; an id that names no active skill is refused. This is DETERMINISTIC — it runs no model and forms no opinion beyond the counted overlap; call refine_search afterwards if you want that. Results never contain contact data — use send_outreach to reach someone. If the run comes back pending, poll get_search with the returned run_id. Runs and delivered profiles are subject to a fair-use read budget — fair use is what the terms of service set out in § 17 — and a refusal carries `retry_after` in seconds.

search_candidates

Save a candidate to the workspace shortlist, optionally against a job. The shortlist belongs to the whole team.

shortlist_candidate

Take one of this workspace's listings back off the public board and out of candidate matching. The listing itself stays.

unpublish_job

Update a CV's name, data and/or theme. Only provided fields change. By default `data` REPLACES the stored document, so any section you omit is lost — pass merge=true to patch the stored CV instead (sections you send replace their counterpart, sections you omit are kept). The response reports received vs. stored counts per section. In a PERSONAL workspace the candidate name is always the signed-in account's — see create_cv.

update_cv

Update fields of one of this workspace's job listings. Only the fields you name change; pass null to clear one. Saving never re-runs the skill detection; after a spec change pass detect_skills=true to re-detect — otherwise the listing keeps its previously detected skills.

update_job

Dry-run: validate a AptoraCV resume document WITHOUT writing anything. Returns whether it is valid, any schema errors, the normalization it would apply, how many entries each section would store versus how many you sent, and any field that is not part of AptoraCV. Use this before create_cv/update_cv to confirm no data is lost. In a PERSONAL workspace the reported normalization includes the identity binding the write would apply, so this dry run and the write agree.

validate_cv

Dry-run a job listing: reports what is missing or would be ignored, and writes NOTHING. Use it before create_job to avoid half-finished listings. Available on every plan, including plans that cannot create listings; detect_skills is the one part that is not.

validate_job