A candidate is a person who will be the subject of a future screening. In many cases, a candidate will be created and screened immediately in a single session. Alternatively, a candidate can be created in advance for future screenings, screened with different packages over time as part of a role change, or may be screened every few months as part of an existing role.

By design, candidate records can be created with only a handful of required fields, to allow for use cases like step-by-step data collection across multiple user interactions. Because different kinds of screenings need different information about the candidate in order to effectively search for their background data, there is no single set of universally required fields for all screening types.

When building code to collect data from candidates within your own application, the best user experience in most cases is to collect all the data you will need in a single form. Because application developers typically know in advance what packages they will use to screen candidates, the best way to ensure that you are collecting all the data you need from your candidates is to look up the list of requiredFields using the Packages resource.

📘
The candidate's email and clientReferenceId must be unique. When updating a candidate, all previously provided fields should be included in the request body with their desired values, not only those fields with intended changes.

The candidate's email and clientReferenceId must be unique. When updating a candidate, all previously provided fields should be included in the request body with their desired values, not only those fields with intended changes.

The candidate's `email` and `clientReferenceId` must be unique. When updating a candidate, all previously provided fields should be included in the request body with their desired values, not only those fields with intended changes.