The context node in the outbound candidate object will look something like this:
{ "context" : {
"job_id" : "R-444",
"candidate_source_id" : "CB",
"candidate_source_name" : "Careerbuilder",
"source_candidate_id" : "cand-411402",
"supplementary" : {
"custom_field_user_id" : "bob-123",
"candidate_status" : "ranked"
},
"source" : {
"job_id" : "R-444",
"custom_field_user_id" : "bob-123"
},
"transformer" : {
"candidate_source_id" : "careerbuilder",
"candidate_source_name" : "Careerbuilder",
"source_candidate_id" : "cand-411402",
"candidate_status" : "ranked"
},
"plugin" : {
"source_mapper" : {
"candidate_source_id" : "CB"
}
}
} }
The following context fields are “known” context fields, which are considered to be commonly found fields used in many candidate application workflows:
It is important to note that all context fields are not guaranteed and will only be included where sufficient data is available for the candidate.
- “job_id” - ID of the job which the candidate applied to
- “shortlist_id” - ID of a shortlist which a recruiter has selected to list the candidate against
- “candidate_source_id” - ID of source from which this candidate originated
- “candidate_source_name” - Nice name of source from which the candidate originated
- “source_candidate_id” - ID of the candidate record within the source system
There will also be a supplementary context node
- “supplementary” - aggregated context information that does not fall into any of the “known” context fields
The remaining context nodes contain all arbitrary context information ( name:value pairs ) that were available during the process at each stage before determining the final context
- “source” - context information provided explicitly from the source
- “transformer” - context information made available during transformation of the source candidate format into the candidate hub format
- “plugin” - context information generated by any plugins that were processed against the candidate