• How has your experience been with the bunq API?

Hi everyone! I'm Tom, one of the product people here at bunq.

As you know, we are a very developer friendly bank, we’re built by a bunch of coders and we love our developer community. 💻

That’s why we built the bunq public API, and OAuth, to enable you to create great experiences with money. 🌈

So what’s next? We are looking for feedback from you on what improvements you would like to see as a developer.

What do you want to see next, that would let you build even more great experiences with bunq? 💪

We can’t wait to hear your suggestions!
Tom

    Just to name a few things from previous topics

    Add support for the implicit grant type for OAuth and get rid of the private information that gets returned for no reason.
    - https://together.bunq.com/d/3436-oauth-returning-private-information-when-creating-a-session/11

    All of the stuff listed here. The second part of that topic has a list of more API requests/suggestions
    - https://together.bunq.com/d/3215-api-issues-and-suggestions

    To make uploading images easier instead of only allowing binary uploads
    - https://together.bunq.com/d/1173-allow-base64-formatform-requests-for-file-uploads-in-the-api

    Give devs access to an aggregated endpoint just like bunq uses internally (/user/{userId}/event)
    - https://together.bunq.com/d/2147-fetch-all-request-inquiriesresponses

      I haven't tinkered with the API recently, so I haven't had the opportunity to work with the new OAuth implementation. 🔐

      But I know there is an issue/annoyance with using OAuth, you can't use your own application in production if you use OAuth, unless you have a second premium/business bunq account. In my eyes this is a big problem if you want to be developer friendly, because developers want to be able to use their own creations! 🌈

      https://together.bunq.com/d/3130-cannot-use-oauth-authentication-on-myself

        I can second what Janson says. This is a blocking problem for developers.

        And I'd like to second Gregory's first point, this is really important if you want publicly released applications!

        I really find it great to be working with this API. It's such an important part of your life which is suddenly open to connect with you in a technologically way.

          Totally agree with @Gregory and @WJanson !

            Same here.

            I do love the API and the possibilities it creates, but there are a few roadblocks that prevents to publish/use apps created with the API.

            It's not very attractive to use oauth when you can't use your own app(s) and it's limited to only one app.

            Although I'd like the more restrictive permissions when using oauth, it would be great if it's possible to be even more restrictive and pick your own permissions.

              @WJanson#32270

              😊 Glad you're excited about the news!

              Thanks to everyone for the input, keep it coming and we will keep you posted on any developments. 🌈

                It would be nice if it was possible to allow future direct debits, just like you can inside the app.

                Also I was told that "notes" can only be added inside the app and are not shown when accessing the event with the API.

                  One of the key points I would like to see is more fine grained permissions for API keys.

                  As an example: I have an application that uses a BunqMeTab to add money to an account. This is not permitted with oauth, so I have to resort to the full access API key.

                  Between full access and read-only, it would be good if there is:
                  - a permission to request money but not send money
                  - the ability to restrict access to specific accounts only, so I can have an application specific account without the application being able to see my other accounts.

                    Official NodeJS Package / API wrapper

                      Permission levels / API scopes!!

                        @Bastiaan#32454 Ok i’ll take a look (again) last time it was not backend ready (browser related packages)

                          @HonderdProcent#32492 You can use it for the back-end but you'll need to use a custom storage system. (The example uses json-store)

                          I should say though, I haven't properly tested it on a NodeJS server before so I don't know how stable it'll be if you run a server for multiple days

                            Another thing that'd make my life easier is if the GET /session/{id} endpoint became public.

                            Right now if I want to keep a session active I have to guess what the exact time is that the session will expire at after I send a request in the last 30 seconds. This works reasonably well but there will always be a few seconds of discrepancy between the time I assume it will expire at and the actual time. That doesn't look like much but it does go wrong over longer durations and in edge cases which is a pain to debug.

                            Using that endpoint I could just send my 'keep alive' request to the GET /session/{id} endpoint and know the exact time that i need to send another request

                              I do not understand one bit about it

                                Subscribing to notifications on monetary transactions has been incredibly helpful in tinkering with the API.

                                I think there would be a great usecase to enable that for non-stop developers to tinker with the API though a webhook with a UI to manage it.

                                This would enable people to use services like IFTTT / Zapier with bunq and come up with great ideas quickly that could latter become real apps.

                                  And yeah, granular permission levels seem really key for you as a bank! I can define every little detail of data I (don't) want to expose in Facebook, so my bank should allow me to do the same, given that the data you have is a lot more sensitive. :)