The details of a candidate can be uploaded to the SEEK API.
This information is used to identify candidates that exist in your software and in SEEK’s Talent Search database when returning search results,
reducing the time hirers spend cross-referencing candidate information with your software.
Candidates that exist in both systems are referred to as shared candidates.Shared candidates shown on the Talent Search website will have a badge indicating that they are shared,
the date the candidate was last updated in your software and on SEEK,
and a deep link back to your software.Talent Search requires that changes to candidate information within your software be reflected in the SEEK API within 60 seconds .An uploaded
Up to 20 interaction history items can be provided in the The following mutations update an uploaded candidate and their profile.
You should use these mutations whenever an existing candidate is updated in your software.
This includes candidates you update in your software using profiles purchased from Talent Search.The
Candidate
object is structured as follows:An uploaded candidate has the following CandidatePerson
fields:- Name
- Email addresses, with at least one required
- Optional phone numbers
- Optional home locations
- Whether they can be contacted
CandidateProfile
containing:- Create and update dates
- Profile actions that deep link into your software
- Preferred work locations
uploadCandidate
mutation adds a new candidate and their profile.
You should use this mutation whenever a new candidate is created in your software.
This includes candidates you create in your software using profiles purchased from Talent Search.To avoid unintentional duplication of data, SEEK enforces uniqueness on an email address of the candidate.
Requests to share a candidate require a seekPrimaryEmailAddress
field with a value that matches one of the given email address values in the person.communication
field.
A request to upload an existing candidate will receive an UploadCandidatePayload_Conflict
result.
The existing candidate will not be updated; you can select their details from the conflict result.If a candidate has expressed a preference to not be contacted,
you should upload them with a seekDoNotContactIndicator
value of true
in the person.communication
field.
This will customise the display name of the candidate in SEEK Talent Search and prevent hirers from contacting them.seekDoNotContactIndicator | Display name |
---|---|
null | Hana Webber |
false | Hana Webber |
true | Hana Webber has elected not to be contacted by Partner |
seekProcessHistory
field during initial upload.
Individual items can be later created, modified and deleted using the relevant interaction history operations.
SEEK strongly recommends providing the first 20 interaction history items when backfilling an existing candidate.
This maximises the rate your software can backfill candidates while reducing load on SEEK’s systems.Keep track of the IDs assigned to the candidate, their profile and their interaction history to perform subsequent update and delete operations.
The UploadCandidatePayload_Success.candidateProcessHistoryItems
field contains the uploaded interaction history in input order for ease of correlation.mutation ($input: UploadCandidateInput!) {
uploadCandidate(input: $input) {
... on UploadCandidatePayload_Success {
candidate {
documentId {
value
}
profiles {
profileId {
value
}
}
}
candidateProcessHistoryItems {
id {
value
}
}
}
... on UploadCandidatePayload_Conflict {
conflictingCandidate {
documentId {
value
}
profiles {
profileId {
value
}
}
}
}
}
}
- The
updateUploadedCandidatePerson
mutation replaces personal details.A request to update the candidate’s email with an existingseekPrimaryEmailAddress
will receive aUpdateUploadedCandidatePersonPayload_Conflict
. The existing candidate will not be updated; you can select the conflicting candidate details from the conflict result. - The
updateUploadedCandidateProfileActions
mutation replaces profile actions. - The
updateUploadedCandidateProfileDates
mutation replaces profile create and update dates.The profile’s update date is intended to reflect when the candidate has been updated in your software. This mutation should be used even if the update isn’t captured by the profile fields you upload to SEEK. - The
updateUploadedCandidateProfilePositionPreferences
mutation replaces profile position preferences.
mutation updateUploadedCandidate(
$documentId: String!
$person: CandidatePersonInput!
$seekPrimaryEmailAddress: String!
$profileId: String!
$seekActions: [CandidateProcessActionInput!]!
$createDateTime: DateTime!
$updateDateTime: DateTime!
$positionPreferences: [PositionPreferenceInput!]!
) {
updateUploadedCandidatePerson(
input: {
candidate: {
documentId: $documentId
person: $person
seekPrimaryEmailAddress: $seekPrimaryEmailAddress
}
}
) {
... on UpdateUploadedCandidatePersonPayload_Success {
candidate {
documentId {
value
}
}
}
... on UpdateUploadedCandidatePersonPayload_Conflict {
conflictingCandidate {
documentId {
value
}
}
}
}
updateUploadedCandidateProfileActions(
input: {
candidateProfile: { profileId: $profileId, seekActions: $seekActions }
}
) {
candidateProfile {
candidate {
documentId {
value
}
}
}
}
updateUploadedCandidateProfileDates(
input: {
candidateProfile: {
profileId: $profileId
createDateTime: $createDateTime
updateDateTime: $updateDateTime
}
}
) {
candidateProfile {
candidate {
documentId {
value
}
}
}
}
updateUploadedCandidateProfilePositionPreferences(
input: {
candidateProfile: {
profileId: $profileId
positionPreferences: $positionPreferences
}
}
) {
candidateProfile {
candidate {
documentId {
value
}
}
}
}
}
deleteUploadedCandidate
mutation deletes an uploaded candidate and their profile.This will erase all uploaded details of the candidate from SEEK’s systems.