Unnecessary updates done in various timestamp based fields by HubSpot

In HubSpot engagement entities like notes, tasks etc. and common entities like deal, ticket etc. there are some fields which are internally updated by HubSpot which shows some tags like INTERNAL_PROCESSING, CALCULATED etc. in the History API response.
Now this date field’s update is changing the hs_lastmodified time of this entities. So due to this, I have a system which considers the number of revisions done by the users to decide whether the entities are needed to be polled or not.

But the issue due to this internal processings and calculations, some unwanted revisions are also being added to this, causing issues in my current system.
So is there any way to identify such properties or fields which HubSpot internally updates which impacts the last modified time.
Or is there any meta provided in the API through which such identification is possible.
Also in the API some fields doesn’t provide any meta related to this like they can be updated using the internal processing but still is updated by the HubSpot processing.
Hence, is there any possible way to avoid such unnecessary updates causing the last modified time to change and also causing increase in the entity revisions once it is created or updated by actual users or by any user’s API.

Hey, @ASuthar :waving_hand: Thanks for your question. It’s a tricky one for sure. My brain wants to suggest Webhooks as an alternative because they will return `changeSource` in the webhook response. The thinking is knowing `changeSource` gives you more details to use to build sorting logic into your process.

Hey @nickdeckerdevs1 @evaldas @Phil_Vallender have you had to tackle anytihng similar in your project work?

Thank you very much for taking a look! — jaycee

But currently my whole infra is set up based on HubSpot APIs and it will have some reasonable amount of cost to set up webhooks.
So I want to suggest that the API meta should be enhanced which can provide the meta information for all such fields, which are being modified or can be modified by HubSpot. In this way we can discard such fields for processing purpose.

Hey, @ASuthar that is 100% valid feedback. I understand. In this case, I can only offer documented options. If you have a product suggestion or feedback for future releases, the Ideas Forum is your best bet for getting that in front of the product team and other users who may share your use case. But for addressing your immediate question, a workaround, like the ones mentioned above, is likely your best option. — Jaycee

OK @Jaycee_Lewis, can you please add this in the product improvements, as this is a major issue, as if someone has not changed the last modified time, by any updates made by him using API or anything, then as the last modified time is changed.
Which can cause issues in audit tracking as well, for systems where integration and migration is performed for the HubSpot as a source or target system with other systems.
Thanks.

As @Jaycee_Lewis pointed out -- webhook subscriptions is a great way to do this -- but if you aren’t looking to do that -- I have a workaround that I use.

i create a workflow that targets the actual important record properties, and I have that trigger an update to a date time property called last updated important. Some portals I do like “partner portal last uodated” and I only have the properties on the deal that should let the user know that their deal has been updated. This prevents notes or emails being logged to the record from triggering this and allows partners to see when actual updates were made.

in the workflow I use OR for all the entry triggers.

Because of recent changes to workflow ui I’d likely trigger on record update or something and then branch and have it OR through those properties. I’m not sure. I’m just a bit bitter about the changes so take that with a grain of salt.