Entity History

Learn about the api to retrieve entity history.

This request is used to retrieve timestamps (UTC) reflecting when an entity was modified, the user who made the changes, and the type of change.

Request

GET {TenantURL} /entities/{entity object URI}/_changes

Table 1. Parameters
Parameter		Required	Description
Headers	`Authorization`	Yes	Information about authentication access token in format "Bearer `<accessToken>`" (see details in Authentication API).
Query	`max`	No	Positive Integer value to identify maximum number of entities to return in a response. Can be used to organize pagination in combination with "offset" parameter. Default value is `50`. This has a hard limit of 1000 records.	`max=10`
	`offset`	No	Positive Integer value to identify starting what element in a result set should be returned in a response. Can be used to organize pagination in combination with "max" parameter. Default value is `0`.	`offset=120`
	`order`	No	Order of sorting. Can be used in combination with "sort" parameter to have reverse order. Possible values: `asc`: the results will be shown in ascending order `desc`: the results will be shown in descending order Default sorting in by entity `desc`.	`order=desc`
	`filter`	No	Enables entities filtering by a condition. Format for filter query parameter: `filter=({Condition Type}[AND/OR {Condition Type}]*)` There are tree Condition Types: `equals`(`property`, `value`): exact match condition ignoring case `lt`(`property`, `value`): '`less than`' condition `lte`(`property`, `value`): '`less than` or `equals`' condition `gt`(`property`, `value`): '`greater than`' condition `gte`(`property`, `value`): '`greater than`' or '`equals`' condition `changes`(`attribute`): match changes for a specific attributes The `'equals`' match condition is applicable for filtering users, who made changes, for history event type, and for timestamps. The '`lt`', '`lte`', '`gt`', and '`gte`' conditions are applicable only for timestamps. The '`changes`' condition is applicable only for filtering events with certain attribute changes. For more information see Filtering Entities	Filter historical events with changes of FirstName attributes, made by 'test.uset' `filter=changes`(`configuration`/`entityTypes`/`HCP`/`attributes`/`FirstName`) and `equals`(`user`, '`test`.`user'`) Filter historical events with timestamp less than specified value. `filter=lt`(`timestamp`, '`1428309071535`') Filter all '`ENTITY_CHANGED`' events. `filter=equals`(`type`, '`ENTITY_CHANGED`')
	`showAll`	No	Specifies if the response should contain all historical events, despite any real changes on attributes. Filter is ignored if `showAll` is set to `true`. Default value is `false`.	`showAll=true`
	showMajorEventsonly	No	Indicates whether the response must contain only major events. When enabled, only the 1000 most recent major events are returned. If disabled, all events are retrieved up to a limit of 1000 Following events are considered major events: ENTITY_CREATED ENTITIES_SPLITTED ENTITIES_MERGED_ON_THE_FLY ENTITIES_MERGED ENTITIES_MERGED_MANUALLY	showMajorEventsonly=true
	`options`	No	Comma-separated list of different options which affect JSON content in the response. Available options: `skipReferenceAttributesProcessing`: disabled by default, defines if delta for reference attributes should be calculated or not. Adding this option may cause excluding of some changes in reference attributes from response, but reduce response time.	`options=skipReferenceAttributesProcessing`

We recommend you use these methods to reduce the response time for a request:

Use the skipReferenceAttributesProcessing option to significantly reduce response time, even when there are no reference attributes.
If there is no changes filter, use showAll=true to also reduce response time.

Note: There is a hard limit of 1000 most recent events retrieved from the database even ifshowMajorEventsOnly parameter is set to true. . Pagination won't work beyond this limit.

Note: Before bringing the data into Reltio, the API converts the source system data to canonical values. When you retrieve the history of the entity, the history view does not transcode anything, and displays the saved record. The saved record holds only canonical values. When you retrieve the current state of the entity, the API executes the transcode again. So, if the localization for a locale is set to a RDM tenant, and the API request has the Accept-Language header, then the API returns the localized transcoded lookup value.

Response

JSON array with timestamps when an entity was modified.

Request

GET {TenantURL}/entities/11/_changes?filter=
    changes(configuration/entityTypes/HCP/attributes/FirstName)
    Headers: Authorization: Bearer 204938ca-2cf7-44b0-b11a-1b4c59984512

Response

GET {TenantURL}/entities/11/_changes?order=asc
    Headers: Authorization: Bearer 204938ca-2cf7-44b0-b11a-1b4c59984512
[{
	"timestamp": 1428308955399,
	"user": "test.user",
	"type": "ENTITY_CREATED"
}, {
	"timestamp": 1428309071535,
	"user": "test.user",
	"type": "ENTITY_CHANGED"
}]

Unify and manage your data

Entity History

Footer