When your app requests a user's data from the Akahu API, it is served a cached copy of that data. Akahu periodically refreshes connected account data from data holders to ensure that your apps view of that data is kept up-to-date. To determine how old the available data is for a given account, you can check the account's
Depending on your specific needs, your Akahu app can be configured to ensure a certain minimum level of data freshness. See Scheduled Refreshes for more detail.
Apps also have the ability to request data refreshes on-demand. You can find out more about this in the Manual Refreshes section.
Akahu does not refresh logged-in party data at the same rate as other connected account data. Party data is seldom updated at the financial institution (i.e. will only change if the user updates their name or address) and can be an expensive operation for Akahu to fetch. Because of this, it is refreshed on a fixed 30 day interval regardless of the scheduled or manual refreshes that are initiated for your app.
When you register an app with Akahu it will be assigned a minimum data refresh rate. By default this is once per 24 hours, meaning that account data served from the API will be at-most 24 hours old1.
If your app requires a higher level of data freshness, additional constraints can be applied to ensure that connected account data is kept at an acceptable freshness level for your use-case2.
Scheduled refreshes allow Akahu to provide your app with a certain level of data freshness for each user. However, we can't guarantee that the data for all of your users has the same level freshness at any given time; each user's data refreshes are scheduled and distributed throughout the day to limit the load that we reflect onto data holder APIs.
If your app subscribes to webhooks, you may notice account data updates occurring more often than your app's refresh rate. This is because Akahu refreshes data optimistically where possible. The most common case would be that the user's account is connected to multiple Akahu apps, of which some may have constraints that result in more frequent refreshes than yours. In this case, your app gets to "tag-along" on the data refreshes that are run for users that you have in common with these apps.
1If Akahu is unable to complete a scheduled refresh for any reason (such as a data holder API outage), data freshness constraints may be not be met. In such cases, Akahu will continue to retry until the refresh completes successfully.
2High frequency refreshes may incur additional costs.
In cases where your app requires a higher level of control over data freshness, a manual refresh can be requested using the
POST /refresh endpoint.
When you request a manual refresh, Akahu may choose not to act on this instruction for some or all accounts if the data for these accounts has recently been refreshed within your apps manual refresh rest period. The default manual refresh rest period is 15 minutes, but this can be customised if your app has specific requirements3. The rest period considers all refresh activity for a given connected account. For example, if you manually request a refresh shortly after a scheduled refresh has completed this instruction may be ignored.
While manual refreshes are necessary in certain cases, it is preferable to rely on scheduled refreshes where possible. If your app abuses the manual refresh functionality by triggering it excessively (i.e. many times per day per user), Akahu may request that you limit this activity.
3Changes to default refresh limits may affect your pricing.
Updated 9 months ago