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