Pipedrive API Documentation

The testing-readme Developer Hub

Welcome to the testing-readme developer hub. You'll find comprehensive guides and documentation to help you start working with testing-readme as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    

Changelog

Subscribe to Changelog

To be notified about new Changelog posts you can turn on notifications in Pipedrive's Developers' Community by pushing the 'follow' button (next to 'New Topic' button) to receive email notifications.

May 2019

Effective from:
June 25, 2019

Daily API limit for POST/PUT endpoints

We're introducing a daily API fair usage limit for POST/PUT endpoints. We consider fair usage 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.

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

The daily limit is introduced in addition to the rate limiting and will apply to all POST/PUT endpoints provided by our API.

Example use-case

Martin is a user of Pipedrive. He has

  • installed two apps from the Pipedrive Marketplace
  • built two custom integrations using the Pipedrive API

Both apps and custom integrations are a 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 installed apps is making 350 POST requests per day and two of the integrations 100 PUT requests each per day, then there's 10000 - 350 - 100 - 100 = 9450 POST/PUT requests left for those two apps and two integrations to use for the remaining time until the reset.

The daily fair usage limit of 10 000 POST/PUT requests will be the same for all three plans (Silver, Gold, Platinum).

Introducing the daily API limit allows us to protect the system from data overload, to have more equal and higher performance distribution in order to handle your requests quicker.

Published on May 24, 2019

Effective from:
May 30, 2019

Additional change in email and phone number quantity limit

What will change?
The number of emails and phone numbers a user can add to a person object will be limited to 50 records each. A user can add a maximum of 50 emails and a maximum of 50 phone numbers per person.

When a person object has reached 50 emails or 50 phone numbers, the UI will no longer show the “+ add more” button for this person. If a 3rd party developer sends more than 50 emails or phone numbers, they will receive an API error. This API error should help to prevent data loss for the customer.

Why?
This change comes in addition to the change announced on May 7th as 3rd party developers can still unknowingly abuse the API - for example, adding thousands of emails and/or phone numbers into one person. This happens regularly a few times per month and it adds a lot of real-time processing demands to our servers, causing slow webapp performance for all the companies that share the same server.

Published on May 17, 2019

Effective from:
May 9, 2019

Adding a deal bug fix

We identified an issue with POST /deals endpoint. It was possible to add last_activity_date and next_activity_date fields when adding a deal.

This has been fixed, because these are values which will automatically be calculated based on the activities linked to the deal.

Please let us know if you have any questions by replying to the forum thread here.

Published on May 17, 2019

Effective from:
May 7, 2019

New limit for importing emails and phone numbers

What will change?
The number of emails and phone numbers a user can add to a “person” type object will be limited to 150 records each. A user can add a maximum of 150 emails and a maximum of 150 phone numbers per person.

When a person object has reached 150 emails, their UI will no longer show the “+ add more” button. If a 3rd party developer sends more than 150 emails, they will receive an API error. This API error should help to prevent data loss for the customer.


Why?
3rd party developers can unknowingly abuse the API - for example, adding thousands of emails and/or phone numbers into one person happens regularly a few times per month. They usually clean up after themselves, but this still adds a lot of real-time processing demands to our servers.


Who is affected?
The most obvious will be companies who already have too many emails or phone numbers per person, as they will no longer be able to add any more emails or phone numbers to their “person” type objects.

Published on May 7, 2019

April 2019

Effective from:
April 22, 2019

related_objects in API response can now be turned off

We have added a new global GET parameter related_objects=0 that will turn off related_objects in API response. We have added it to boost performance and improve response time for the data you really need.

Published on April 22, 2019

Effective from:
May 9, 2019

Removal of the /users/{id}/activities endpoint of the Users resource

We will be removing the following endpoint from the Users resource:


This endpoint was deprecated 1.5 years ago. In case you are still using the above-mentioned API endpoint in your code or 3rd party app/integration, please remove any dependency on this endpoint.


You have the option to replace it by using GET /activities endpoint by passing the user_id parameter. You will get the same exact response with the addition of related_objects being added to the output.

Published on April 9, 2019

March 2019

Effective from:
April 14, 2019

New size limit for notes

We will be decreasing the size limit for notes. There will be no need to edit existing notes, but after April 14th it will not be possible to create notes larger than 3MB.

We decided to decrease the note size to approximately 3,000,000 characters (or 3MB per note) because large-sized notes reduce application memory and affect the performance negatively.

If your code or 3rd party app/integration has been designed to create or update notes, please doublecheck these as they may fail if the note being created or updated is too large.

Published on March 19, 2019

February 2019

Effective from:
December 2, 2019

Removal of the /authorizations endpoint

We will be removing the Authorizations endpoint:

We deprecated this endpoint on February 28, 2019, and we strongly advise you to avoid the use of this endpoint. The /authorizations endpoint is a legacy way of authorization using generic API keys. Such an approach does not provide transparency into which applications have access to data nor the opportunity to control the permissions these integrations have. Therefore we suggest using OAuth Authorization instead.

In case you are using the /authorizations API endpoint in your code or 3rd party app/integration, please remove any dependency on this endpoint as soon as possible.

Published on February 28, 2019

Effective from:
February 11, 2019

Removal of permissionSetAssignments endpoints of the Users resource

We have removed the following endpoints of the Users resource:

  • GET/users/{id}/permissionSetAssignments
  • POST/users/{id}/permissionSetAssignments
  • DELETE/users/{id}/permissionSetAssignments

In case you are using the above-mentioned API endpoints in your code or 3rd party app/integration, please remove any dependency on this endpoint.

Published on February 11, 2019

January 2019

Effective from:
January 30, 2019

Field selector in requests with OAuth

Field selector is now also supported in requests done with OAuth. Note that most endpoints in our API Reference support this, but not all. See examples of field selector usage here.

Published on January 30, 2019

Effective from:
January 28, 2019

New webhooks policy

We are implementing a new webhooks usage policy in order to provide more stable and continuous deliveries, at a more reasonable rate. It will affect both general and App-Specific webhooks. Read more about it in Webhooks policy.

Published on January 22, 2019

December 2018

Effective from:
December 14, 2018

more_items_in_collection key added to /searchResults response

The more_items_in_collection key was missing from the output of /searchResults endpoint, so we added it. Here is an example:

"additional_data": {
	"pagination": {
		"start": 0,
		"next_start": 100,
		"more_in_provider": false,
		"more_items_in_collection": false
	}
}

Published on December 14, 2018

Effective from:
December 6, 2018

New rate limits window now in effect

We have now changed the rate limits window per access_token (or api_token) for all three plans.

You can see the current rate limit window versus the previous rate limit window for each plan (the old ones are the crossed out ones):

Plan
API rate limit

Silver

100 requests per 10 seconds per access_token (or api_token)
20 requests per 2 seconds per access_token (or api_token)

Gold

200 requests per 10 seconds per access_token (or api_token)
40 requests per 2 seconds per access_token (or api_token)

Platinum

400 requests per 10 seconds per access_token (or api_token)
80 requests per 2 seconds per access_token (or api_token)

Published on December 7, 2018

Effective from:
January 21, 2019

Deprecation of Transport Layer Security (TLS) 1.0 and 1.1 Encryption Protocols

We are going to disable the TLS 1.0 and 1.1 encryption protocols in order to apply the industry's best practice for security.

Please make sure your manual/custom integration with Pipedrive is updated to TLS 1.2. In case of any questions, please head to the Developers’ Community Forum to discuss and learn more.

Published on December 5, 2018

November 2018

Effective from:
December 21, 2018

Deprecation of permissionSetAssignments endpoints of the Users resource

We will deprecate the following endpoints of the Users resource:


In case you are using the above-mentioned API endpoints in your code or 3rd party app/integration, please remove any dependency on this endpoint.

Published on November 21, 2018

Effective from:
December 6, 2018

New rate limits window

We are going to change the rate limits window per access_token (or api_token) for all three plans. This change allows us to have higher performance and handle your requests quicker.

You can see the current rate limits for your plan here and the new limits below:

Plan
API rate limit

Silver

20 requests per 2 seconds per access_token (or api_token)

Gold

40 requests per 2 seconds per access_token (or api_token)

Platinum

80 requests per 2 seconds per access_token (or api_token)

Published on November 6, 2018

Changelog


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.