Gregory GoijaertsProdigy
After checking the functionality some more I have found a few things which are quite odd in my opinion.
OAuth doesn't let you use your own client (there is already a topic for this so I won't go in depth on this)
You can only have one OAuth client. This looks fine at first until you realize that developers often have multiple applications. If for some reason I have to reset my client, I'll have to re-enter my client info on all my applications. Or if I want to run a test application I can't quickly share a temporary client id which I can delete afterwards.
This also means that the user will have to reconfirm that they want to login instead of the instant login flow that you'll see with for example Facebook and Google logins after logging in once before.
And more importantly if one of my applications is compromised somehow, ALL applications will be compromised.
The chat api was deprecated without a warning or wait period. It just got dropped without a warning which is absurd for a public API.
I know some users will go, "it's not a big deal, just use the new notes system". But nope, not only is the notes system a one way message solution it isn't even public. So I can't use it.
This is slightly unrelated and more a personal opinion than a real issue. The new developer screen looks great and it is functional. But I get the feeling that features are dropped or not implemented just to keep everything as clean as the rest of the app. And as a developer I don't want a basic but extremely user friendly screen, I want control over my projects and settings. I'd rather have a dashboard similar to Google's advanced system than what we have right now.
Inconsistent object names. When implementing the connect api I was only able to figure out why it wasn't working with help from a bunq employee. Since all of a sudden an object name isn't written as "read_only" but as "ShareDetailReadOnly".
Seeing how I've helped 3 other people on together with this exact same issue I'm definitely not the only one running into this.
This is also a documentation issue but in general expecting developers to suddenly use a completely different notation in specific cases is quite confusing.
And just to link to a few more existing topics/features which would make things so much easier for me and other developers.
An events endpoint for all monetary accounts or a different alternative for the callbacks. That way you'll get significantly less traffic from applications which are unable to use the callback system. bunqDesktop is unable to use it and many other clientside apps will run into the same issue. I'd rather not spam your API with polling requests but there isn't a viable alternative. 🤷🏻♂️
base64 or other formatting for the binary data: https://together.bunq.com/d/1173-allow-base64-formatform-requests-for-file-uploads-in-the-api
Allow cross-origin requests. With JS frameworks becoming more and more popular you'd open up the API to literally millions and millions of JS developers: https://together.bunq.com/d/1758-allow-cross-origin-requests
More options for sandbox testing for bunq.me and card payments. It is impossible to test these on the sandbox so you are forcing developers to test in production: https://together.bunq.com/d/2591-simulate-card-payments-in-sandbox
I'll probably think of more things when I'm back from my holiday but these are the main issues and improvements I can think of right now.