Handling sessions

Any service accepts and returns an optional session object that can be passed to consecutive calls of the same or other services to possibly avoid authentication or authorization steps or at least speed things up.

While it might still work, a session object should be considered obsolete after passing it to a service.

Long-lived connection data

While sessions expire after a short amount of time and thus are not meant to get persisted, there is also the concept of long-lived connection data. In case credentials get persisted on the client for regular access, it is recommended to store and update connection data with them whenever a service returns some. Just like sessions, passing such data can avoid authentication and authorization steps and speed things up.

Redirects

Note that the session object typically does not help with redirect authentication steps (unless redirect scraping is enabled on the connection for you). Make sure that cookies stay available between redirect steps, so that providers might pick up their session again.

Recurring consents

For regular access to account information, you can opt in to recurring consents. The client SDKs provide interfaces to set a respective flag on initial service calls. Whenever a consent is required to access certain resources and no recurring one is already available, the service will request a recurring one with maximum permissions.

Make sure to handle connection data properly, as they carry the necessary consent data.

By default, the service requests a one-time consent with targeted, minimum permissions.

As some providers display detailed consent information, minimal one-time consents are ideal for single-use cases, while recurring consents make sense when onboarding users for regular access.