Measurement Sync Tracking Best Practice

Forum
1

Hi everyone,

I have a question regarding measurement synchronization and tracking in Cumulocity IoT.

After checking the API and documentation, it looks like measurements are read-only after creation, and update operations are not supported for measurements.

Example measurement response:

{
  "id": "69faf70baf830b60b0d7b4d2",
  "type": "c8y_Temperature",
  "source": {
    "id": "12168"
  },
  "time": "2026-05-06T08:08:43.054Z"
}

Currently the response contains:

  • id
  • time
  • source.id

but I do not see a createdAt / creationTime field

I would like to understand the recommended approach for:

  • tracking already processed measurements
  • avoiding missing data during downtime
  • handling delayed/offline device measurements

Questions:

  1. Is there any recommended sync tracking approach for measurements?
  2. Is there any way to query measurements based on creation/received time instead of measurement time?
  3. Is there any supported way to update or tag measurements after creation?
2

Hi anushka and welcome to the Cumulocity community! :waving_hand:

Measurements are very volatile, meaning, will be ingested with a very high frequencey. Updating them would not make any sense. Instead it is suggested to post new measurements.

I assume with “already processed measurements” you mean processed for synchronization?

This state needs to be stored & maintained outside of the measurements documents. Your sync application must have logic to remember which queries & documents has been processed as I stated, it would not make much sense to read every single measurement and put/read a state there.

To your questions:

  1. Build measurement queries e.g. small time windows, query them, process them, remember & store that this query has been processed already e.g. storing the number of processed measurements to the start and end timestamp of your query. Or in more detail: Storing all IDs of all processed measurements if double processing it critical.

Please note: Potentially it is possible that measurements with a timestamp in the past and future can be created. So it might be that same query to a later time result in more documents than before even when the timestamp you used for the query points to the past.

You could also leverage Notification 2.0: Create a subscription for measurements, sync them 1:1 directly instead of polling the API with query. Also a combination make sense: Polling & syncing “old” measurements, for newly created measurements sync them directly using Notification API.

  1. No, only time is possible.

  2. No, as explained above, that would not make any sense to put a sync state to a measurement document.