Configure OdataLink to poll for changes

From OdataLink
Revision as of 22:19, 2 August 2026 by Nic (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Overview

Polling allows OdataLink to quickly check for changes. If no changes were made since the data was last retrieved, OdataLink will source the data from the archive. However, if changes were made, it will retrieve the latest data from your data file.

Sourcing the data from the OdataLink's internal archive is vastly superior in terms of speed and performance than needing to retrieve the data from the source.

How the Page By option affects polling

When OdataLink pages the data by month, quarters, half-years or years, it creates small partitions in the archive. Rather than having to poll for changes applied to the whole request (e.g. 2 or 3 financial years), it can then use these smaller partitions to check if data changed in a single month or year. This results in improved performance.

Since it's likely only the recent months contain changes, we strongly recommend you use Page By Month for optimal performance.


How the Archive Cut Off Date affects polling

The archive cut off date takes priority over polling.

When you formally configure your Odata Feed with an archive cut off date of 31 December 2025, you're instructing OdataLink that the data prior to this date is locked and will never change. As such, data prior to this date will ALWAYS be sourced from the archive and OdataLink will NOT poll for changes in those periods. It will only poll for changes in months or years after that date.


What the sensitivity setting is used for

The sensitivity option is there for those that are likely to change the dates of transactions and moved them to other months.

It is easier to illustrate it's use with an example. If a transaction is moved from February to March, OdataLink can poll for changes in February but it is likely that MYOB or Xero would indicate no changes. This is because there are no modified transactions in February (since it is now in March). The sensitivity setting allows OdataLink to establish a wider date range for polling purposes.

When sensitivity is set to +/- 1 month, rather than constrict checking for changes only in February, it will send a call asking if anything changed in January to March. If the answer is yes, it will refresh February. It will do the same for March by checking February to April and so on. This doesn't mean that January data will appear in February. It just means that if anything changed between January to March, we should refresh February to be on the safe side.

When sensitivity is set to +/- 2 month, it would use December to April when checking for changes in February.

Doing this allows OdataLink to keep the archive up to date when transactions dates are changed.


Why use the option to force a full refresh

For most endpoints, forcing a full refresh is not needed. As such, we strongly recommend you use the option NEVER force a full refresh regardless of how old the archive data is..

However, depending on how you built your power queries, it may be beneficial.

The first situation relates to meta data. When polling for changes, changes made to meta data endpoints (e.g. account numbers) will not trigger a change in other endpoints like transaction endpoints. That is because the transaction wasn't actually changed. Instead, it's the account number or name that changed. While we recommend always sourcing data from the related endpoints, this is not always possible. In those situations, forcing a refresh every 24 or 48 hours can be beneficial.

The second situation relates to specific endpoints. The main one is contacts in Xero. Similar to the scenario above, some fields in the contacts endpoint can change without actually Xero flagging changes in the endpoint. This applies to 3 specific fields: IsCustomer, IsSupplier, Balances.

The formal recommendation is to use NEVER force a full refresh regardless of how old the archive data is. unless you experience issues with polling for changes.


Which endpoints currently support polling

Polling for changes was primarily built to increase performance and reduce the costs Xero decided to charge for their API in December 2025. As such, we prioritised the following endpoints: Xero Accounting Endpoints

The plan is to have all endpoints support polling in some form or another but prioritising the ones used most.

Retrieved from "https://help.odatalink.com/index.php?title=Configure_OdataLink_to_poll_for_changes&oldid=4692"