See what changed on a record
Every edit to a layer feature property is appended to a log. That log is how you answer “who closed this ticket”, “when did this deviation get resolved”, or “what moved since yesterday” without diffing snapshots yourself.
The call
Section titled “The call”curl -X GET "https://api.sitemark.com/propertyChanges?layer_feature_id=<layer-feature-id>&_pageSize=100" \ -H "Authorization: ApiKey <your-api-key>"Use the integer id from the layer feature, not its visible_id. History is always read per
layer feature, up to 200 ids per call.
Reading the entries
Section titled “Reading the entries”Each entry names the property that changed, the value before and after, and who made the change.
The property_key is either:
- a built-in key —
STATUS,ASSIGNEE,VOLUME— which is its own name and is not in the property definitions list, or - a property-definition UUID, which you resolve to a name via List property definitions.
Narrowing to one property
Section titled “Narrowing to one property”To follow just the status of a ticket, filter by key:
curl -X GET "https://api.sitemark.com/propertyChanges?layer_feature_id=<layer-feature-id>&property_key=STATUS&_pageSize=100" \ -H "Authorization: ApiKey <your-api-key>"property_key only narrows within layer_feature_id — it cannot be used on its own, and takes at
most 200 keys.
Paging a long history
Section titled “Paging a long history”A record edited often has a long log. Property changes documents the fields in full and how to page a complete history reliably — worth reading before you build a polling job on top of this.