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

Plan	API rate limit
Essential	20 requests per 2 seconds per `api_token`
Advanced	40 requests per 2 seconds per `api_token`
Professional	80 requests per 2 seconds per `api_token`
Power	100 requests per 2 seconds per `api_token`
Enterprise	120 requests per 2 seconds per `api_token`

Rate limiting for OAuth apps using access_token

Plan	API rate limit
Essential	80 requests per 2 seconds per `access_token`
Advanced	160 requests per 2 seconds per `access_token`
Professional	320 requests per 2 seconds per `access_token`
Power	400 requests per 2 seconds per `access_token`
Enterprise	480 requests per 2 seconds per `access_token`

Rate limiting for Search API

Plan	API rate limit
Essential	10 requests per 2 seconds per `api_token` and `access_token`
Advanced	10 requests per 2 seconds per `api_token` and `access_token`
Professional	10 requests per 2 seconds per `api_token` and `access_token`
Power	10 requests per 2 seconds per `api_token` and `access_token`
Enterprise	10 requests per 2 seconds per `api_token` and `access_token`

HTTP headers and response codes

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

Header	Description
`x-ratelimit-limit`	The maximum number of requests current `access_token` or `api_token` can perform per 2-second window.
`x-ratelimit-remaining`	The number of requests left for the 2-second window.
`x-ratelimit-reset`	The remaining window before the rate limit resets.
`x-daily-requests-left`	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.

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 our API is heavily used. If this impacts you, 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 integration architecture, using Webhooks, and/or upgrading to Advanced, Professional or Enterprise plan.