Rate limiting


User's UI actions are counted in the rate limit. Webhooks are not subjected to rate limiting.

All our API endpoints require authentication. Regardless of the authentication method, the Pipedrive API allows performing requests according to the plan.

While the Pipedrive API rate limit window duration is 2 seconds for both authentication methods, the rate limiting of the Pipedrive API is different for api_token requests and OAuth apps using access_token.


Rate limiting of the Pipedrive API is considered per token, not per company.

See below how each of our four plans offers different rate limiting per 2-second window for both authentication methods:

Rate limiting when authenticating with api_token


API rate limit


20 requests per 2 seconds per api_token


40 requests per 2 seconds per api_token


80 requests per 2 seconds per api_token


120 requests per 2 seconds per api_token

Rate limiting for OAuth apps using access_token


API rate limit


80 requests per 2 seconds per access_token


160 requests per 2 seconds per access_token


320 requests per 2 seconds per access_token


480 requests per 2 seconds per access_token

HTTP headers and response codes

Each Pipedrive API request will include the following rate limit response headers:




The maximum number of requests current access_token or api_token can perform per 2-second window.


The number of requests left for the 2-second window.


The remaining window before the rate limit resets.


Indicates how many requests you can still make to POST/PUT endpoints during the ongoing day (calculated in UTC). Applicable only to api_token requests. See more here.

For example, after a successful request has been made from an Advanced plan account, the API response headers would look like this:

x-ratelimit-limit: 40
x-ratelimit-remaining: 39
x-ratelimit-reset: 2
x-daily-requests-left: 9999 // This field only appears in responses for POST and PUT endpoints.

If you exceed the rate limit, our API will start rejecting your requests and you'll receive an error response of HTTP 429 "Too Many Requests" in the body:

{"success":false,"error":"request over limit","errorCode":429}

Daily API fair usage limit for POST/PUT endpoints

In addition to rate limiting, public API has a daily API fair usage limit for all POST/PUT endpoints. Fair usage is considered to be a maximum of 10 000 POST/PUT requests daily per user per 24 hours. The daily limit will be reset at midnight in UTC.

How the limit for 10000 requests per day per user is calculated?

Martin is a user of Pipedrive. He has two custom integrations using the Pipedrive API. Both custom integrations are subject to the same daily limit to make requests against the Pipedrive API on behalf of the user, Martin. So, for example, if one of those integrations is making 350 POST requests per day and the other integration 100 PUT requests each per day, then there's 10000 - 350 - 100 - 100 = 9450 POST/PUT requests left for those two integrations to use for the remaining time until the reset.

The x-daily-requests-left in the response header will indicate how many requests you can still make to POST/PUT endpoints during the ongoing day. See how the full header would look like in HTTP headers and response codes.


We strongly recommend integrations built using api_token and apps using OAuth 2.0 to follow the daily fair usage limit of 10000 POST/PUT requests.

In the case of exceeding the 10 000 daily limit on multiple occasions, we may start blocking your POST/PUT requests towards our API.

Blocking high volume traffic


Only the high volume traffic coming from api_token integrations will be blocked.

In order to protect ourselves from online attacks caused by misconfigured API integrations, users abusing our system by not respecting our rate limits and keeping up the high volume of traffic despite getting the 429 response code, will also get the 403 response code. When getting the 403 response code, the answer will be an HTML error page with the message "This error is produced by Cloudflare. See troubleshooting guide here.", informing the user that one’s access has been denied:

Please note that this improvement will not impact the vast majority of users, even if there is heavy usage of our API. If you are impacted by this, please review your integration and remove any misconfiguration that might lead you to be blocked.

How to avoid being rate limited

If you're reaching the rate limit, options to improve performance include restructuring the architecture of the integration, using Webhooks, and/or upgrading to Advanced, Professional or Enterprise plan.

Read next
Did this page help you?