Input Parameters - Person Changelog API

​

Required Parameters

​

api_key

Your API Key must be included in either the request header or the api_key parameter. For more information about request authentication, see the Authentication page.

​

origin_version

The valid versions that can be provided for input are:

• Any of the last 3 monthly releases
• OR any of the last 2 quarterly releases

For example as of v28.2, these would be:

• Monthly: 28.2, 28.1, 28.0, 27.2
• Quarterly: 28.0, 27.0, 26.0

Note that the origin_version must be less than current_version

​

current_version

The valid versions that can be provided for input are:

• Any of the last 3 monthly releases
• OR any of the last 2 quarterly releases

For example as of v28.2, these would be:

• Monthly: 28.2, 28.1, 28.0, 27.2
• Quarterly: 28.0, 27.0, 26.0

Note that the current_version must be greater than origin_version

---

​

Optional Parameters

​

type

Type	Description	Default	Example
String	Specifies the type of changelog to return. This field is required when not submitting a list of ids (via the ids field).Supported values: added, deleted, updated, merged, opted_out		added

​

ids

Type	Description	Default	Example
Array [String]	List of person IDs to query changes for. Minimum length: 1 Maximum length: 60,000		["123", "qEnOZ5Oh0poWnQ1luFBfVw_0000", "345", "678", "000", "111"]

Passing this field allows you to filter the query results to return only changes in the records containing the specified IDs. The ids field must be an passed as an array of IDs (corresponding to PDL person IDs from the Person Schema). The length of this array must be be at least 1 and less than 60,000.

​

fields_updated

This field is only supported when providing the "type": "updated" in the input query. Fields must be passed as an array of top-level fields from the Person Schema. Examples of top-level fields are fields like:

• experience (but not experience.company.title)
• education (but not education.degrees)
• etc

If any invalid fields are provided, the API will return an error with details on list of valid field names (see error.valid_fields_updated

​

scroll_token

A scroll_token returns in every response from the Person Changelog API and serves as a placeholder or bookmark for the last record received. For queries with more results than can fit in a single API response (see the size field), use the scroll_token to get the next batch of results. For example, if you send a query to the Person Changelog API that has 1000 matching records, you will need multiple API calls to retrieve all the records. The scroll_token represents how far along you are in that list of records. Generally, the way to use scroll_token is:

1. Send a query to the Person Changelog API.
2. Get a response back containing one batch of records as well as a scroll_token response value (if you have already retrieved all the available records in this batch, then the scroll_token value will be null).
3. Use the same query from Step 1 and the scroll_token you just received to make another request to the Person Changelog API.
4. Get another response back with the next batch of records and a new scroll_token value.
5. Repeat steps 3 and 4 until you have received the desired number of records or until you receive a 404 status code because pagination is complete and the scroll_token key is missing from the response.