While adding Notes to Contacts order is not maintained.

Developer Support APIs & Integrations
1

I’m currently working on an integration product called OpsHub Integration manager.
There I’m syncing data between two HubSpot entities source - Ticket and target is Contact. In this sync I’m syncing the Notes added in the ticket entity as well to the target contact entity.
The issue currently I’m facing is. I have three Notes added in the Ticket entity as mentioned below:

Note ID Created Time Content Updated Time Type

87957048760 1756980855421 R 1756981394298 ticket_to_note
87957960966 1756980856933 R2 1756981394909 ticket_to_note
87955252140 1756980858511 R3 1756981395079 ticket_to_note

Here we the order of adding the Notes is correct R → R2 → R3 according to their created and updated time as well.
Now when I sync the ticket entity to the corresponding Contact entity created with the Notes content is shown below:

Note ID Created Time Content Updated Time Type

87956884357 1756981003701 R 1756981004147 contact_to_note
87955252407 1756981006614 R2 1756981007006 contact_to_note
87942187098 1756981004993 R3 1756981005459 contact_to_note

Now here main observation is the create time of R2 is greater than the create time of R3 also the same behavior is observed in the update time as well.
Also this is occuring once in 20 times I run this integration. Also for clarification, no updates on this Notes are made by my API ( used for the integration), still the updated time and the created time differs.
So can anyone please tell is there any issue with the API for creating the Note engagement, as by looking at this inspite of same order of creation in Ticket entity, the target contact entity is not reflecting the similar order of Notes. And have different created and updated time.
Using APIs only in the product no workflows are configured.
Thanks.

2

Hi @ASuthar
Thank you for reaching out to the Community!
I’d like to invite some community members who are subject matter experts to join this conversation.
@zach_threadint @SteveHTM @coldrickjack - Would you be able to share any insights on this? Your expertise would be greatly appreciated.
Best,
Victor

3

Hi @ASuthar :waving_hand:

Are you specifying the property “hs_timestamp” (as per this documentation) when you create the Notes via API? This should give you control over the create date of the Notes being created.

If you are already specifying this property, would you please share some example API calls?

I hope this proves helpful. Please let me know if you have any follow-up questions.
Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.

4

Hi @zach_threadint, thanks for your reply,
The time I’m mentioning here is the hs_timestamp mentioned in the documentation, which is mandatory to add while making a POST request for creating the Note engagement.
The issue is after my creation, there are multiple updates performed on that Note, leading to the multiple updates in its hs_lastmodifieddate value.
I have verified this by fetching the History of one of the Note entity and what I got is:

“hs_lastmodifieddate”: [

{

“value”: “2025-09-04T16:21:00.931Z”,

“timestamp”: “2025-09-04T16:21:00.931Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T16:21:00.417Z”,

“timestamp”: “2025-09-04T16:21:00.417Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:23:15.079Z”,

“timestamp”: “2025-09-04T10:23:15.079Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:18:22.435Z”,

“timestamp”: “2025-09-04T10:18:22.435Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:18:22.332Z”,

“timestamp”: “2025-09-04T10:18:22.332Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:14:24.017Z”,

“timestamp”: “2025-09-04T10:14:24.017Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:14:21.259Z”,

“timestamp”: “2025-09-04T10:14:21.259Z”,

“sourceType”: “CALCULATED”

},

{

“value”: “2025-09-04T10:14:19.497Z”,

“timestamp”: “2025-09-04T10:14:19.497Z”,

“sourceType”: “INTERNAL_PROCESSING”,

“sourceId”: “RecordSourceDetailsWriterWorker”

},

{

“value”: “2025-09-04T10:14:18.511Z”,

“timestamp”: “2025-09-04T10:14:18.511Z”,

“sourceType”: “INTEGRATION”,

“sourceId”: “2825542”

}

]
From the above response it is clearly visible that after My Integration with Id 2825542 created the Note at “timestamp”: “2025-09-04T10:14:18.511Z” which I have added during the creation of Note, after that multiple Updates on the last modified date has been performed.
Which leads to the case when at some time point, when I fetched these Note entites lets at T3, there I got the last modified timestamp of the Note R2 greater than the R3, even If it is created in correct order. This issue is due to this multiple internal updates.
So I just want to ask that is there any way to stop this updates to modify the hs_lastmodifieddate as I’m using this field to poll the entities which are changed after a particular time. So due to this unnecessary updates, I’m getting wrong order of data. Leading to mismatch in sync.
Thanks, looking forward for your reply @zach_threadint.

5

Hi @ASuthar — thanks for sharing the detailed follow-up, that’s super helpful context. Just to confirm, has Zach’s suggestion around using hs_timestamp helped you get closer to resolving the issue, or are you still running into the ordering problem because of the internal updates to hs_lastmodifieddate?

Also, @SteveHTM made a good point about checking for other workflows or sync processes — did you get a chance to rule that out as well?

And @zach_threadint — do you happen to know of any additional workarounds to prevent or account for those internal updates, since they seem to be affecting the sync order?

Thanks everyone!

Best, Victor

6

Hii Victor,
Thanks for your reply, as mentioned by @zach_threadint , the hs_timestamp related issue was not present, actually the main culprit here is the internally updated being performed by the HubSpot, leading to the updation of the hs_lastmodifieddate field, which is being used by our product in order to make decision like whether to poll the entity and perform the necessary operations.
This similar issue is occuring in other entities as well like Deals, Tickets, Contacts etc. Where once using API we performed the create or update event then after that HubSpot performs many internal updates and modified the timestamp for the hs_lastmodifieddate field.
Hence this leads to unnecessary polling of entities.

7

Hi @ASuthar and thanks for getting back to us.
Here are some alternatives to reduce polling:

- Use Webhooks instead of polling
The Webhooks API is recommended over regular polling. You can subscribe to “propertyChange” events for specific properties on Contacts, Deals, Tickets, etc.
This way, you only get notified when actual changes occur, avoiding internal HubSpot updates.

- Consider the Webhooks Journal API (BETA)
The Webhooks Journal API provides historical event data for the past 3 days and is optimized for checking what changed, which is more performant than polling with the CRM Search API.

I hope this helps!
Have a lovely day!
Bérangère
This post was created with the assistance of AI tools.

8

Thanks @BérangèreL , for such a speedy response,
Actually my current application architecture supports the REST API model, so for that I’m unable to shift the whole architecture to WebHooks.
So what I want to know, is there any way to discard the internal updated performed by the HubSpot using REST APIs. Or else in case any system level settings can be done which can stop this internal updates to be performed.
If not the both cases mentioned than is there any other timestamp than the hs_lastmodifeddate which is not being impacted by the internal HubSpot updates and updates only when actual human or API changes are being taken place.
Also, from this I want to understand why such internal updates are being performed by the HubSpot system, if so, why it leads to change in the hs_lastmodifieddate field which is a very important field for tracking and auditing the changes made on the entity.
Thanks, hoping for your speedy response.

9

Hi @ASuthar and thanks for your message.
At the moment, there is no way to prevent internal HubSpot system updates from modifying the hs_lastmodifieddate field for Contacts using REST APIs.

The documentation confirms that hs_lastmodifieddate is updated by both user/API changes and internal system updates.
Let’s consult with our Top Experts: Hi @Anton, @sylvain_tirreau and @SteveHTM can you think of a workaround to help @ASuthar, please?
Have a great day and thanks so much!
Bérangère

10

Hii @BérangèreL , thanks for your response, actually I also want to understand the usage of these internal HubSpot’s system updates.
As this updates are not done by any user or API integrations, then don’t you think that this updates should be externalise using some other separate system fields, such that its impact is not being visible on the core system fields like created and modified time fields.
As this might be a challenge for auditing as well in integration and migration systems.
Thanks

11

Hi @ASuthar, thanks for your feedback!

The best way to share this is through the HubSpot Developer Feedback form so it gets directly to the right team.
If you’d like, I can submit it on your behalf, just let me know.

Thank you,
Bérangère

12

@ASuthar - I have to comment that I have never seen this type of behavior. If the API call origininally specifies a Note timestamp, then that’s how it displays on the activity record - at least in all instances I have worked on.

The only thing I might want to check on is other workflows or sync processes that derive data from the Contact activity - but “Calculated” is an odd label to see in this context. Just as a reference, I don’t use a sync process in this cross object context, but explicitly add associations to the Note object to make it display in the timeline of each related object record.

Steve
Moderator note: While this solution may not address the original poster’s specific situation, it could be helpful for other community members facing similar challenges.