When to use it
Two scenarios, one feature:- Interrupted session — the end user closed the tab or navigated away mid-MFA. Bring them back to where they left off.
- Refresh an existing connection — a previously authorized account needs fresh data, and the financial institution requires MFA again (e.g., Nightly Refresh failed, on-demand transaction update, MFA answers changed at the bank).
How it works
Pick the entry point that matches your starting state.Interrupted session — you have a live requestId
Reload Flinks Connect with the existing requestId. The end user lands directly on the MFA prompt — no restart.
203 from a session API call means MFA is pending and the session is resumable.
| Token | Validity |
|---|---|
requestId | 8 minutes of inactivity |
| Authorize token | 15 minutes |
requestId has expired, the end user will need to start a new session.
Refresh — you have a stored loginId
Call /Authorize with:
LoginId— the customer’s existingloginIdMostRecentCached: false— force a live connection to the financial institutionSave: true— persist the refreshed data
203 with security challenges. Open Flinks Connect with the same requestId and have the end user answer the MFA there:
requestId to retrieve fresh data.
Preserve previously selected accounts
If the original session used the Account Selector, pass the previously selected account IDs into the Reconnect iframe withresumeSelectedAccounts. Flinks Connect skips the selector, applies the filter on the backend, and surfaces the IDs in the REDIRECT event and redirect URL — so /GetAccountsDetail returns only the originally selected accounts.
Common use cases
- Refreshing data when Nightly Refresh has failed for an account
- Collecting updated transaction history on demand
- Re-authorizing when an account’s MFA answers have changed at the bank