We have a fix for this issue that is currently being tested. If all goes well, I expect this to be part of next release (9.59) which is scheduled for next week. ... View more

Of course we will fix this issue. This was just to offer a possible workaround until the problem is fixed. ... View more

Seems this might be related to role access set up for the branch. One can choose a role that a user must have in order to access a branch. This is administered in screen CS101500: If a role is stated here, the user associated with the API request must have this role in order for the logic behind to successfully access the branch. When using the service-API, there is no ordinary user associated with the API request, but rather a system user associated with the integration client. These "users" will not have regular roles. A workaround is to let this field be empty, or set it to "Administrator". We will find and remove these limitations; when using service-API, all branches should be available. However, there are some endpoints requiring a "human user" to be associated with and API request - for the time being, these are only accessible via the interactive-API since only these are associated with a "real" user. ... View more

The "restrictive limit" we are talking about here is to limit the number of concurrent/simultanious/parallel requests for the same client/tenant combo. This limitation won't affect anyone that is not issuing a lot of concurrent requests for the same company.   Did you try to issue 1000 requests in parallel towards the same company in one of the other systems you integrate with? ... View more

>Interesting way to treat your customers. Let them solve your performance problems by breaking existing clients. Reason behind this is that some customers are in fact issuing a lot of concurrent requests, and some of these require rather heavy queries on the database. Such api requests will have a long lifetime and will cause servers to be drained of resources if not limited, and other api requests (also for other clients) will slow down and might also time out. So, if not handled, you will notice clients breaking, and that would not be a nice way to treat customers.   >Since you have already implemented the request counting on the server, to return 429, I will in most cases use that functionality and just do a retry on 429+ConcurrentRequestsLimitPolicy until it succeeds.   Yes, you can do that, and if you have that 4** response status handling in place (as you should) and a retry policy in place, then your client is not breaking by this. But instead of hammering with numerous retries in all situations, it is a much better solution to inform what is the exact problem so that a client can more elegantly handle it.   >Still don't understand what real world problem you are trying to solve here. Do you get a lot of "unnecessary" requests you hope will disappear with this solution? Have you asked the API-users why they send so many requests?   The real world problem is that resources are not unlimited. So instead of letting clients fail miserably, it is better to share the availability in a controlled way. We will of course at the same time discuss alternative solutions with those integrators that send thousands of simultaneous API requests. We will also continuously work to improve endpoints that have performance issues and better scale our server resources. But as long as there is no solution to all problems overnight, rate-limiting seems in order. The 429 status code was "invented" for a reason. In the real world most services do not allow unlimited concurrent requests -- this could even be interpreted as a DOS or DDOS attack by security measures.   ... View more