• Developers

  • API rate limiting does not function in accordance with documentation and is too low to be usable

This problem actually started somewhere in the past one or two weeks. Before that, there didn't seem to be any (significant) rate limiting, as I could make seemingly endless calls to the API without getting rate limited.

According to the API documentation:

Our rate limits per IP address per endpoint:

However, when simply retrieving information about an account with

MonetaryAccount::listing($context, $userId)->getValue();I sometimes randomly get the error

HTTP Response Code: 429 Too many requests. You can do a maximum of 1 POST call per 1 second to this endpoint.even when I only make one request after waiting multiple seconds.

First of all, the error does not match the documentation. 1 call per second is different from 5 calls per 3 seconds.

Secondly, the error does not match what is actually happening. I am not making more than one call in one second. I am making only one call and then waiting a bit until I try again.

Finally, the rate limit is way too low for any real-world application. For example, I am trying to allow people to link multiple bunq accounts to the account they have in my app. Then, they can view a list of their linked accounts. This list is produced using the command I stated above. Now if any user has more than one bank account linked (or 5 if the rate limit would match the documentation), simply displaying their accounts triggers the rate limiting.

I would like to stress that this worked perfectly fine up until one or two weeks ago. My implementation hasn't changed. I did upgrade the bunq php sdk to version 0.12.3, but I don't know if this could have anything to do with it.

Any ideas on this from bunq developers? Thanks!

    Hey Wouter,


    Do you make another call before you call MonetaryAccount::listing($context, $userId)->getValue(); ?

    AFAIK the post limit is indeed 5 within any 3 consecutive seconds with exception to the session-server endpoint. The session server endpoint is limited to 1 call per second.


    The SDK will automatically reset a session if it has ended before making a call, but it does not save the new session automatically. I have a felling you're making a call before "MonetaryAccount::listing($context, $userId)->getValue();" with an outdated API context and therefore the SDK resets the session more then once, hence reaching the rate limit.


    Is this indeed the case ? To confirm, can you vardump the uri parameter before the request is made: https://github.com/bunq/sdk_php/blob/d303c7a8b4330b5b972f389ba66045693d93f83f/src/Http/ApiClient.php#L372


    And see on which endpoint your getting this error message, I have a feeling it will be on session-server.


    Please let me know if this is the case indeed!

      That does seem to be what's happening! I checked the context files I have and they expired a couple of days ago.

      Before the MonetaryAccount::listing call, I'm calling BunqUser::listing. Both result in a call with 'session-server' uri.

      Looking at the stack trace it seems the context updates itself after restoring the session. However, I used a copy of the old context for each call, so it wasn't updated properly. Assigning the context to a variable before making all the calls seems to solve the problem.

      Of course, the context that is stored in a file or database is not updated. If I understand correctly, I should manually update the stored context after a series of API calls, or after calling ensureSessionActive. Is that correct or is there a different option I'm missing?

      Thanks for the help!

        Ah I had the felling that this was indeed the case hehe!


        What you could do is the following:

        // Session reset scheduled command $apiContext->resetSession(); // If your saving to file $apiContext->save(); // If you need to save it somewhere else. $apiContext->toJson();This will reset the session, afterwards you can save the context or extract the json and save it to database!


        Let me know if this helps!

          a month later

          great information, thank kevin and wouter!

          i have the same HTTP 429 too many POST issue problem. I have app clients to access php server(sdk_php) simultaneously, the php server have many 429 execptions.

          Now using $apiContext->resetSession(); at begin and using $apiContext->save(); at end, these 429 execptions have been reduced to an acceptable rate.

            a month later

            Kevin,


            you wrote "AFAIK the post limit is indeed 5 within any 3 consecutive seconds with exception to the session-server endpoint. The session server endpoint is limited to 1 call per second.


            This is (still) not reflected in the documentation: https://doc.bunq.com/api/1/page/errors

              2 months later

              Bump on this


              The session server endpoint is limited to 1 call per second.

              This seems still not documented...

                6 months later

                @Shopforce-B-V-Maroon-Butterfly#10955 The session server endpoint is limited to 1 call per second.

                @Shopforce-B-V-Maroon-Butterfly Is this still the case? I'm running into rate limiting as well, and like to know the exact rate limits that apply before going in and making changes to my code.

                Also I agree with @Wouter-Red-Falcon#377 that the rate limits might be too low to be usable. If I'm paying Bunq €7.99 per month to be able to use their API, I would like to have a little higher rate limits. Especially important (imho) is to have separate burst limits. Look at Auth0 for example: They have 15 requests per second, but allow bursts up to 50 requests!

                  Write a Reply...