Candidate Context Node

The context node in the outbound JSON payload 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",
            "locale": "en",
            "rank": "SUITABLE",
            "rank_time": 0,
            "screened": 0,
            "username": "testuser@testteam.testoffice.testclient"
        },
        "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"
            }
        }
    }
}

An inbound context node payload could look something like this:

{
    "context": {
        "job_id": "R-444",
        "supplementary": {
            "aplitrak_email_address": "john.doe.1234.23456@clientname.aplitrak.com"
        }
    }
}

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
• “subsource” -Upstream origin of the candidate application, if applicable

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