Configure OdataLink to poll for changes

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.

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.

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.

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

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 Endpoint: Contacts
• Xero Accounting Endpoint: ContactsExpanded
• Xero Accounting Endpoint: ContactsExpandedTable
• Xero Accounting Endpoint: Invoices
• Xero Accounting Endpoint: InvoicesExpanded
• Xero Accounting Endpoint: InvoicesExpandedTable

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