You can share candidate interactions that occur in your software.
This provides hirers with a consolidated view of interactions across your software and SEEK:
Changes to candidate interaction history within your software should be reflected in the SEEK API within 60 seconds.
Individual interactions are represented by a
CandidateProcessHistoryItem type .
Each item is associated with the CandidateProfile of an uploaded candidate and listed under the seekProcessHistory field.An interaction may occur outside of the context of a particular position:
JSON
Copy
{"action": {
"code": "Note",
"name": "Contact again later",
"description": "Candidate not currently looking for work, try again in six months. Keen to stay in Melbourne."
},
"actionDate": "1999-07-26T23:48:58.775Z",
"idempotencyId": "00000000-0000-0000-0000-000000000001",
"primaryParties": [
{
"person": {
// For interaction history, `communication` fields are not displayed in
// SEEK Talent Search
// They can be omitted or set to empty arrays
"communication": {
"email": [],
"phone": []
},
"name": {
"formattedName": "Terry A",
"given": "Terry",
"family": "Astley"
}
}
}
]
// `positionProfile` and `seekSource` are omitted for a general interaction
// `status` is omitted for a non-`CandidateWorkflowTransition` action
}actionhas a freeform name, description and one of the following codes:CodeDefinitionAgencySubmissionA candidate was sent by an agency to the hirer for general considerationDocumentA document was attachedEmailAn email was sentNoteA note was addedPhoneCallA phone call was madePostPlacementActivityA post-placement activity occurred, e.g. a satisfaction surveyScreeningA screening activity occurred, e.g. an interviewVerificationActivityA verification activity occurred, e.g. a police checkStatusChangeThe availability of the candidate has changedOtherAny other action that doesn’t fit into the other bucketsnameis the hirer-visible name for the workflow step. For example, the hirer might have defined a “Second interview” step that maps to the SEEK API’sScreeningaction code.
An interaction may be scoped to a given opportunity by providing the associated position profile:
JSON
Copy
{"action": {
"code": "CandidateWorkflowTransition",
"name": "Initial offer",
"description": "Progressed to offer stage"
},
"actionDate": "1999-12-26T12:31:43.185Z",
"idempotencyId": "00000000-0000-0000-0000-000000000002",
"primaryParties": [
{
"person": {
"communication": {
"email": [],
"phone": []
},
"name": {
"formattedName": "Hayden R",
"given": "Hayden",
"family": "Robinson"
}
}
}
],
// `positionProfile` and `seekSource` are required for placement information
"positionProfile": {
"profileId": "globalPublicTest:positionProfile:unposted:QnwpqZfzXu1NRmZw5tjswn"
},
"seekSource": {
"name": "Recruitment Agency"
},
// `status` is required for a `CandidateWorkflowTransition` action
"status": {
"code": "Offer"
}
}actionmay use any of the prior codes, with one addition:CodeDefinitionCandidateWorkflowTransitionThe status of the candidate for this opportunity has changedseekSourceindicates the initial source of the candidate in the context of this opportunity. The same value should be resent for each item in the process.statusmust be provided for aCandidateWorkflowTransitionaction, following a rough order of progression:CodeDefinitionApplicationInitial state in the hiring processAgencyShortlistShortlisted internally by an agency prior to submission to the hirerAgencySubmissionSent by an agency to the hirer for consideration for this opportunityHirerShortlistShortlisted by the hirerInterviewInterviewing/interviewed for the opportunityTestingOrQualificationsCheckCompleting/completed tests or verification of their qualificationsReferenceCheckHaving/had their references checkedOfferOffered the positionSuccessfulAccepted the positionUnsuccessfulNo longer being considered for the position
The
createCandidateProcessHistoryItem mutation adds a record of an interaction between the candidate and a SEEK hirer.To avoid unintentional duplication of data, SEEK enforces uniqueness on a partner-provided
idempotencyId.
A request to create an existing item will receive a CreateCandidateProcessHistoryItemPayload_Conflict result.
The existing item will not be updated; you can select its details from the conflict result.Keep track of the IDs assigned to the process history item to perform subsequent update and delete operations.
MutationVariablesSuccess resultConflict result
CopyGraphQL Explorer
mutation ($input: CreateCandidateProcessHistoryItemInput!) {
createCandidateProcessHistoryItem(input: $input) {
... on CreateCandidateProcessHistoryItemPayload_Success {
candidateProcessHistoryItem {
id {
value
}
}
}
... on CreateCandidateProcessHistoryItemPayload_Conflict {
conflictingCandidateProcessHistoryItem {
id {
value
}
}
}
}
}The
updateCandidateProcessHistoryItem mutation replaces a candidate process history item in its entirety:MutationVariablesResult
CopyGraphQL Explorer
mutation ($input: UpdateCandidateProcessHistoryItemInput!) {
updateCandidateProcessHistoryItem(input: $input) {
candidateProcessHistoryItem {
id {
value
}
}
}
}The
deleteCandidateProcessHistoryItem mutation removes a candidate process history item from the candidate profile.MutationVariablesResult
CopyGraphQL Explorer
mutation ($input: DeleteCandidateProcessHistoryItemInput!) {
deleteCandidateProcessHistoryItem(input: $input) {
candidateProcessHistoryItem {
id {
value
}
}
}
}