Skip to main content
A job’s hiring team is the set of people responsible for hiring on it — hiring managers, recruiters, interviewers, and so on. Each member is either matched to an organization member or pending.
Once a hiring team member is matched (has an organization account), they are notified about this job: a daily applicant digest covering the jobs they are on (opt-in per member), plus an email when a new application arrives or an interview completes if the job enables those notifications. Pending members are notified only after they join the organization.

​
Manage a job’s hiring team

Adding a member. Send exactly one identifier — zero or both returns 400:
Roles. job_roles is a list drawn from HIRING_MANAGER, RECRUITER, COORDINATOR, SOURCER, INTERVIEWER, ADMIN. It may be empty, and PATCH replaces it.
A person appears on a job’s team once (keyed by email). Re-adding the same email — or an email already held as a pending row — returns 400. Send an Idempotency-Key header to make a retried POST replay the original 201 instead of erroring.

​
List organization members

Use this to discover the organization_member ids (and emails) you assign to a hiring team: Each row is a membership: the top-level id is what you pass as organization_member, role is the member’s org role (owner, admin, editor, viewer), and user carries their first_name, last_name, and email.
These endpoints, like every v2 write, are authorized by the organization-scoped API key alone — there is no per-role restriction, so any key for your organization can manage its hiring teams. The key is owned by a WorkOS user and is revoked automatically when that user leaves the organization; there is no service-account owner. Have a long-tenured team member own the key and rotate it before off-boarding.