Skip to content

Read all tickets of a site

Tickets — punch list items — are the work tracked on a site: something to fix, someone to fix it, a status that moves. Unlike detections they belong to the site, not to one flight.

Terminal window
curl -X GET "https://api.sitemark.com/layerFeatures?site_id=<site-id>&semantic_type=PUNCH_LIST_ITEMS&_pageSize=1000" \
-H "Authorization: ApiKey <your-api-key>"

That is every ticket on the site. Paginate with _page until you reach pagination.pageCount — see Pagination.

Filtering tickets by operation_id returns nothing. They are site-level and persist across flights; scoping them to a single capture matches no records. Same for components and annotations — see Data model.

This is the part that trips people up. Most properties are keyed by property-definition UUID, but ticket status and assignee are built-in properties: they come under their own names, STATUS and ASSIGNEE, and they are not in the property definitions list.

{
"id": 481920,
"visible_id": "PL-142",
"properties": {
"STATUS": "IN_PROGRESS",
"ASSIGNEE": 3312,
"3f2a1c84-...": "custom property — resolve this one"
}
}

STATUS is one of TO_DO, PLANNED, IN_PROGRESS, RESOLVED, WONT_DO or CLOSED, and ASSIGNEE is a user id.

You can also sort on them directly — _sortBy=properties.STATUS — and built-in keys sort correctly whether or not the request is scoped to one dataset. See List layer features.

So when you build your UUID → name map from List property definitions, leave any key that is not a UUID exactly as it is rather than treating the lookup miss as an error. See How properties are keyed.

Every edit to a ticket property is appended to a log, so you can poll what moved instead of re-fetching everything:

Terminal window
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>"

See See what changed on a record for the full pattern, including how to page a long history reliably.

Annotations read the same way — swap the semantic_type. They are created per flight, so filter by operation_id for one flight, or by site_id for every flight at once. See Semantic types for the values.