Fill the gap between Connect and API functionality

Hans shared this idea 5 days ago

While both the Connect feature and the API are wonderful, there's still a functionality gap that might be closed by allowing API use without the API consumer being tied to a user account. My comparison between Connect and the API:

Connect - pros

  • Easy to use
  • Fine grained access controls
  • Grants access per monetary account, not per user.

Connect - cons

  • Can only connect to a user (person or company), which makes it impossible to use for self hosted software (either a desktop/mobile application or a web based solution). When using this to share data with for example a third party's web app such as bittiq, the app's developer will need to register an API key and place it on their webserver. That way, the application can act as a user and access all connected monetary accounts.

API - pros

  • Allows access to features not available through the app, such as more detailed notification filtering, finely crafted payment requests etc.
  • Can be used for self hosted software such as desktop/mobile applications or self hosted web apps.

API - cons

  • Provides the application with unrestricted access to all money and data available to the associated user.
  • Bit more difficult to setup than Connect when used for third party applications.

So the API allows a piece of software to act on a certain user's behalf, whereas Connect allows a monetary account to be accessed by a user other than its owner.

Wouldn't it be cool if the API would allow a DeviceServer to craft a 'Draft Share Invite' directly? The resulting QR code could be scanned by the user who can then decide to share a monetary account with this app instead of sharing it with a user (person or company).

This way, when someone installs an app such as bunqDesktop on my PC, it would create a keypair. With that it would create an Installation and a DeviceServer, but after that it wouldn't need require a full access API key to create a SessionServer. It would be able to draft a share invite and show the QR code on the screen. The share invite could be for read-only access or allow transaction up to a certain amount. The user would be able to scan that QR code from the bunq app and would see that it wants an app called 'bundDesktop' wants to connect to one (or more?) of my monetary accounts.

When the Connect gets accepted by the user, there should probably be a way to start a session, based on the installation token. But that's only relevant if the above sounds like a good idea to begin with :)

Comments (3)


Hi Hans, thank you for your feedback! The option to have multiple levels of API keys has been requested before, for example a read-only API key: I do see that your wish is different, so let's see if other bunqers would like to see this too! 👍


Quite a while ago I suggested using oauth2 for the api, since it makes more sense in a lot of ways. See here: So perhaps that's something to be (re)considered?


I remember reading that topic. oauth2 might work, but would require a lot of changes. My hope was that with only a few minor changes, it would be possible to prevent the scenario you wrote about in that topic:

With my setup, the generated key and the token associated with the Installation could even be stored in the user's browser. I'm not sure if that would be possible with oauth2 as well as I'm not familiar enough with its design.