Skip to main content
Solved

Sync API does not pull changes to data


Hi,

 

I have been trying to use the sync API to try and pull changes from a data model - specifically node instances from a view. When testing, some fields within a view was changed / updated but I was not able to pull anything new using the sync API. This was after I created a baseline of the full dataset using the Query endpoint.

The sync endpoint did work when new nodes were added to the view, it would only pull the new row, so I think my query is correct. Is there some sort of parameter to turn on / other way to use the sync API to retrieve changes and new additions to instances?

Best answer by Arild Eide

I really think you should only submit cursors to the sync endpoint that are issued by sync, even though you might find that cursors from /instances/query also seems to work. Are you able to paginate through the full set using only the sync endpoint?

 

Arild

View original
Did this topic help you find an answer to your question?

Arild  Eide
Seasoned Practitioner
Forum|alt.badge.img
  • Seasoned Practitioner
  • April 2, 2025

Hi ​@duncan.murray 

 

I think the sync endpoint will return both instances that have been created and mutated since the previous call to sync, provided the request includes the cursor returned in the previous call and the instances still satisfy the filter in the request.

There is a general description of the sync endpoint and how it differs from the query endpoint in the documentation as well as an example available in the Python SDK documentation.

 

Hope this helps

 

Arild Eide


Arild Eide wrote:

Hi ​@duncan.murray 

 

I think the sync endpoint will return both instances that have been created and mutated since the previous call to sync, provided the request includes the cursor returned in the previous call and the instances still satisfy the filter in the request.

There is a general description of the sync endpoint and how it differs from the query endpoint in the documentation as well as an example available in the Python SDK documentation.

 

Hope this helps

 

Arild Eide

Yes this is exactly what I’m expecting but when data mutates/changes in the source, I am not able to pull it at all - I get nothing back from the sync with the cursor used from the last full load query. From what I’m reading in the documentation this seems like a bug. 


Arild  Eide
Seasoned Practitioner
Forum|alt.badge.img
  • Seasoned Practitioner
  • April 7, 2025

Hi ​@duncan.murray 

When you say full load query - you are referring to the cursor returned from the first call to sync? And you do provide same filter?

 

Arild


Arild Eide wrote:

Hi ​@duncan.murray 

When you say full load query - you are referring to the cursor returned from the first call to sync? And you do provide same filter?

 

Arild

We do a full load query as a baseline initially and use the last cursor from that as the cursor in the sync - only if it is not expired (three days lifespan). The filter is exactly the same in the sync. 


Arild  Eide
Seasoned Practitioner
Forum|alt.badge.img
  • Seasoned Practitioner
  • April 22, 2025

I really think you should only submit cursors to the sync endpoint that are issued by sync, even though you might find that cursors from /instances/query also seems to work. Are you able to paginate through the full set using only the sync endpoint?

 

Arild


Arild Eide wrote:

I really think you should only submit cursors to the sync endpoint that are issued by sync, even though you might find that cursors from /instances/query also seems to work. Are you able to paginate through the full set using only the sync endpoint?

 

Arild

This was where I was going wrong, I was using the query endpoint to get the full baseline of data and then using the sync endpoint to get changes/new data. Instead I got the full baseline using the sync endpoint and then use the last cursor to get changes successfully. Thank you ​@Arild Eide  


Reply


Cookie Policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings