Partner Connect
Let your users connect their bank accounts through open-banking.io and read the data with a delegated, zero-knowledge key.
#What you get
A partner integrates open-banking.io through Connect: a standard OAuth 2.0 authorization-code flow (with PKCE) that ends with two artefacts for each user who authorises your application:
- an API key (
ebk_…) scoped to that user's connected accounts, and - the user's private key, relayed straight from the user's browser to your callback, which decrypts the account and transaction envelopes the API returns.
Nothing on our side can read the user's data. The server stores encrypted envelopes and hands out keys to read them only through the consent page, only to a registered redirect URI, and only after the user has approved your client by name.
#The two artefacts
| Artefact | Where it comes from | Lifetime |
|---|---|---|
| Access token / API key | POST /oauth/token after the consent page relays a code | 365 days, or until revoked |
| Private key | The consent page form-posts it to your redirect URI next to the code | For as long as the user keeps their keys |
#One user, one tenant per partner
Every user who connects through your client lives in a tenant of their own, keyed by your partner id and the email they signed in with: wl:{partner}:connect:{email}. Accounts, sessions and transactions are scoped to that tenant. A user who connects the same bank through two partners has two independent tenants and two independent sets of keys.
#When access ends
Revoking a key — through POST /oauth/revoke, the user's own settings page, or a partner suspension — makes every subsequent request with it answer 401. Treat 401 as "ask the user to connect again", never as a retry.
#Read next
- Getting started — provisioning your Enable Banking application and your Connect client.