POST /v1/hires. It creates a prefilled
draft offer, not a starter. In andteam a hire is final when the offer is signed. That is when
employee.hired is sent. Creating a starter directly would skip the hiring decision, the offer
approval and the letter, so the API does not.
HR opens the draft in the offer wizard with everything your ATS knew filled in, picks the contract
type and sends it. The approval chains run as they do for any offer. HR gets a task to complete the draft,
in the same list as offers started in andteam.
The call needs the Hires Write switch.
The request
Never accepted: ID or passport numbers, race, disability or bank details. The candidate gives these in
onboarding, where they are gated.
The answer
201 with the hire’sid, status: "draft" and consoleUrl, the offer wizard opened on the draft. Send
HR the link if your ATS shows one. Every POST needs an Idempotency-Key: see
Retries and versions.
Statuses
A hire movesdraft, awaiting_approval, approved, sent, signed. It can end as withdrawn or
declined. A hire is also withdrawn when the candidate’s record is closed before the offer is signed. GET /v1/hires/{id} shows where it is, and reads back only hires the key filed.
hire.status_changed is sent on every move, with data.hireId, data.status and data.externalRef,
so your ATS can follow without polling. A webhook endpoint hears it with the Hires group.
Duplicates
- The same
externalRefagain is 409duplicate-hire, with the existing hire’sexistingId. Read that hire instead of creating another. - A candidate whose personal email matches a current employee is 409
possible-rehire. Nothing is created. HR decides whether it is a rehire, and starts it in andteam.