Rate limiting issues

Hello,
We have set 10 requests per 2 seconds limit on our side, but we’re still getting too many requests errors. Upon examining it closely, I noticed that in the headers you’re returning, the window size is 10 seconds long and we have to wait 10 seconds not 2. Why is that? Your documentation says that the window size for search API is 2 seconds and 10 requests.

Another question, are the search API limits counted separately from the main limits? Do you mean I can issue a total of 90 req / 2 sec against the API: 10 req / 2 sec for the search API plus 80 req / 2 sec general one?

GET https://companydomain.pipedrive.com/v1/organizations/search?api_token=XXX&term=5569253734&fields=custom_fields

Resulted in:

HTTP 429 Too Many Requests

access-control-expose-headers: X-RateLimit-Remaining, X-RateLimit-Limit, X-RateLimit-Reset
alt-svc: h3=":443"; ma=86400
badi: Routing: eu-central-1=>eu-central-1; Version: 67b6; Host: 78469b58d9-k8cg8;
Cache-Control: no-cache
CF-Cache-Status: DYNAMIC
CF-Ray: 8119ad303eab9555-DUB
Connection: keep-alive
Content-Type: application/json
Date: Fri, 06 Oct 2023 00:09:36 GMT
Retry-After: 10
Server: cloudflare
Set-Cookie: XXX
Strict-Transport-Security: max-age=31536000; includeSubDomains
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
x-correlation-id: 5863a8ad-06f6-4d30-96e1-52f88e564a80
x-envoy-upstream-service-time: 6
x-ratelimit-limit: 10
x-ratelimit-remaining: 0
x-ratelimit-reset: 10
X-XSS-Protection: 1; mode=block
```

Hi @Monto :wave:, Welcome to the community

I’d start with the second part of your question

I noticed that in the headers you’re returning, the window size is 10 seconds long and we have to wait 10 seconds not 2. Why is that?

Our APIs have a penalty set when the rate limit is reached. Among others, this helps us protect ourselves from online attacks caused by misconfigured API integrations. Therefore, in case the rate limit is reached, the x-ratelimit-reset header is set to 10.

We have set 10 requests per 2 seconds limit on our side, but we’re still getting too many requests errors.

From what I had a chance to test, the rate-limiting for search is working properly. Can you try to increase the time between the calls slightly? A few milliseconds and see if this helps?

Another question, are the search API limits counted separately from the main limits?

If you hit an override and get HTTP 429 and try to make a request to the endpoint which has a default rate limit rule applied, then the other request should get through normally, and the counter will start incrementing from 0 (assuming no other requests were made to default rule meanwhile).

Hi @Jakub_Netrh

We are getting the same issue 429 with reset as 10s:

x-ratelimit-limit: 10
x-ratelimit-remaining: 0
x-ratelimit-reset: 10

But when this situation is happening, even waiting 10s and making request will produce the same error. Sometimes it is getting through, returning the response, but the limits are still same 10-0-10.

Please note that rate-limit usually applied based on 429 error code, meaning that until you receive this code, no limiting is applied on the retry… Also you should note that on the system it can be multiple independent clients who are working with API and they do not know about rate-limits of each other. In this case we should use either different API key for different client (what is not suitable for background workers and webhooks etc… or we should somehow keep a distributed cache of “rate-limit”.

The ordinary flow of 429 is:

  • make the request
  • if receive 429 header, check the retry-after (standard header) and retry after mentioned in this header seconds
  • if after retry receive 429 again, based on the number of retries, the client should either repeat the request after retry-after seconds or finish the execution with 429 error propagation.

Based on your response about penalty if the situation is happening with multiple workers, then they will be “blocked” by your penalty system and no normal execution can be performed.

I would recommend you guys to use the proper standards of how rate-limiting should be done, penalties and other stuff should not be applied on 5-10-20 throttled request as it is not even close to DDoS and sometimes does not indicate the misconfiguration but rather the concurrent/parallel solution.

Best regards,
Sergei