Consent & reconnection
Bank access is granted by consent that expires. Here is how expiry works, what it does to the API, and how you reconnect.
How consent works
Under open banking, you grant time-limited, read-only consent for an app to access your account. That consent has an end date, after which the bank stops sharing new data until you renew it. This is a regulatory feature, not a Connect limitation, and it applies to every real bank connection.
In the UK, connections also carry a 90-day reconfirmation checkpoint: roughly every 90 days you reconfirm that you still want the app to have access. For many banks this can be handled in-app without going back through the full bank authorization, and the checkpoint advances each time it is reconfirmed.
Expiry warnings
We watch consent end dates and, while a connection is still healthy, warn you ahead of time: the portal dashboard shows a renewal prompt and you receive an email when renewal is due, about ten days before the deadline. That gives you a window to renew before anything stops updating.
You can also see this programmatically: GET /accounts returns consent_renewal_due on every account, the UTC timestamp by which its connection's bank access next needs renewing (the reconfirmation checkpoint for UK connections, the consent end date for EU ones). It is null for connections whose access does not time-expire, such as US and Canadian connections. Alert on it in your own tooling instead of waiting for the feed to go quiet.
What expiry does to the API
This is the important part, stated plainly. When a connection expires (or is suspended by the bank):
- Accounts stay. The account and connection keep appearing on the API; they do not disappear.
- Existing data keeps being served. Every transaction, balance and holding already synced remains available through the API.
- Syncing stops. No new data is fetched from the bank until you reconnect, so the feed goes quiet and balances stop moving. The connection's
statustells you this (expiredorsuspended). - Billing continues. An expired or suspended account keeps counting toward your billable total until you deactivate it (or the connection moves to an error state). Deactivating stops billing and keeps the history available.
Detecting a stalled connection
GET /connections and act on the status field. A status of expired or suspended means the data you hold is still valid but no longer updating. Do not infer this from a stale last_synced_at alone (see Data freshness).Connection statuses
The status on a connection is one of the following machine strings:
| Status | Meaning |
|---|---|
| linked | Consent granted; the connection syncs normally. |
| awaiting_auth | Authorization was started but not completed at the bank. |
| rejected | Authorization was declined at the bank. |
| suspended | The bank revoked access. Data is still served; syncing has stopped. |
| expired | Consent reached its end date. Data is still served; syncing has stopped. |
| error | The connection is in an error state. |
| initiated | A connection attempt has just started. |
Reconnecting
To resume syncing, you reconnect the bank from the portal (or reconfirm consent where the bank supports the in-app path). Once reconnected, the connection returns to linked, syncing resumes, and any data captured during the gap is brought up to date on the next sync. The account keeps its identity across a reconnection, so your stored ids stay valid.