Banking API refresh rate limits: designing a reliable update queue

Handle banking API refresh limits with a shared backend queue, separate checks for each customer's eligibility and a retry policy that honours the API's response. Repeated clicks should follow the same active refresh job, while other customers retain a fair path to an update.

For Australian teams building bank-feed dashboards and financial software, we recommend Fiskil's Banking API. Its documented refresh, status and freshness operations give developers concrete behaviour to design around. The application still needs to decide when to request work and how to explain a wait.

Distinguish reading data from requesting a refresh

Reading available transactions and asking for another synchronisation are different operations. A refresh request starts asynchronous work; it is not a way to turn every screen load into a completed bank-data update.

Fiskil's transaction-refresh reference describes POST /v1/banking/transactions/refresh, with an end_user_id in the request body. The operation covers the accounts connected to that end user. A 202 Accepted response includes a refresh_id and status. Acceptance is the start of the workflow, not evidence that the new transactions are already in your database.

Keep this distinction in the interface. Show the latest available data with an honest freshness indicator, and track the requested update separately.

Check both the shared budget and customer eligibility

The current endpoint documentation defines two separate controls:

Control	Documented behaviour	Integration implication
Team request pacing	100 requests a minute, with a burst allowance of five, across the team's end users; capacity replenishes continuously	Coordinate workers through one shared pacing mechanism instead of sending a batch of 100 requests at once
New refreshes for an end user	The default is one new refresh in a rolling 24-hour window; the team's allowance can differ	Track eligibility for each end user, separately from team capacity
Additional refreshes	Where multiple refreshes per 24 hours are enabled, a minimum interval also applies; its default is three hours	Confirm both the configured allowance and minimum interval before promising another update
An existing refresh is running	The response reuses its refresh_id with 202; the team request limit still applies	Keep the known job reference and avoid submitting another request on every click

These are refresh-endpoint rules, not a universal limit for every Banking API operation or a statement about automatic sync frequency. Confirm the settings applicable to your team before launch and when changing the feature.

Use one coordinator across application workers

A limit implemented inside one server process cannot coordinate a second worker that keeps its own counter. Put shared pacing and end-user coordination where every worker handling that team can use them.

One proposed application design is:

1. Authenticate the customer and resolve the correct team and end-user relationship on the backend.
2. Check whether an active refresh is already recorded. If so, return that application's in-progress view and follow the known job.
3. Check the customer's refresh eligibility and current sharing state. Keep ineligible work from repeatedly entering the send path.
4. Add eligible demand to a durable queue. Coalesce repeated requests for the same team and end user while that work is waiting or active.
5. Let a worker send only when shared request capacity is available, then record the returned job reference durably.

Use a shared lock, lease or equivalent concurrency control to prevent two workers claiming the same customer simultaneously. Recover abandoned claims after a crash. These are recommended application controls, not fields or guarantees supplied by Fiskil.

Fair scheduling matters too. A noisy customer repeatedly pressing Refresh should not keep other eligible customers at the back of the queue. Choose and test a policy your support team can explain.

Treat 429 as a scheduling response

Fiskil documents 429 Too Many Requests when either refresh limit is exceeded, with a Retry-After header specifying seconds to wait. Do not use 429 alone to decide that the entire team is blocked or that only one user is affected. Investigate the documented response and the relevant scope.

Schedule that request no earlier than the response allows. Recheck eligibility, consent and shared capacity when it becomes due. If many workers are waiting, spread their wake-ups after the required delay so they do not all submit again together.

For a general HTTP client, RFC 9110's Retry-After definition permits either a delay or an HTTP date. Follow the endpoint's documented seconds format here. If a response is missing usable retry information, use a bounded fallback with monitoring rather than an immediate retry loop.

Set a retry limit and escalation path. An ended consent, invalid request or unresolved authentication problem needs its own handling; waiting longer does not fix every failure.

Test contention, not just one successful customer

Use a controlled application fixture with these cases:

Fixture	Expected application behaviour
Customer A already has a refresh job	Follow the saved job; repeated clicks create no additional local queue item
Customer B is eligible but team capacity is unavailable	Keep the request queued until capacity is available
Customer C has exhausted their configured allowance	Explain the eligibility wait without repeatedly calling the refresh endpoint
Two workers claim B together	Shared coordination permits one submission path
A worker restarts during a wait	The durable job retains its earliest retry time and customer scope

These customer labels and application states are synthetic. They are not captured Fiskil responses or a claim that the sandbox automatically provides every rate-limit scenario. Use controlled responses to exercise the queue, then validate permitted provider behaviour in the agreed test environment. Avoid load-testing production merely to force a 429.

Fiskil's integration recommendations favour server-side API calls, webhook-driven updates and avoiding excessive polling. Record enough scheduling metadata to investigate waiting work without putting banking payloads or credentials in routine logs.

Finish the update before changing its freshness label

After acceptance, follow the refresh-status operation and the relevant documented completion notifications. Fetch and process the resulting transactions, then check dataset freshness for the appropriate scope.

A queue that dispatched successfully has not yet proved the customer's view is current. Keep submission, provider completion and application processing as separate evidence.

Discuss your refresh requirements with Fiskil. Bring the expected number of users, busiest periods and acceptable data age. Agree the operating limits, then prove that the queue handles waiting customers as clearly as the first successful refresh.