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.
January 27, 2021
companydomain
to replace api-proxy
in API requests
What?
From now on, we’re suggesting you to use https://companydomain.pipedrive.com/api/v1/
API domains for making requests to Pipedrive API. Read more about Pipedrive API URL naming convention here.
Why?
This suggestion comes in addition to the change announced on Feb 21 last year when we introduced a new parameter api_domain
in OAuth 2.0 /oauth/token
responses for our external developers to receive up-to-date company_domain
and api_domain
every time one makes the initial request to get the tokens or when one refreshes a token. Also, using the companydomain
prefix should make your requests to our API faster.
Published on January 27, 2021
January 15, 2021
New parameters in App actions' URLs
App actions triggered from the Activity list view will now have additional parameters activity_type
, activity_start_date
and activity_end_date
added to the URL of the action to describe a filter that has been applied to the selected activities. These parameters will be included in the filter
parameter.
The activity_type
parameter will always be included in the URL for actions from the Activity list view, activity_start_date
and activity_end_date
will be added only when they are selected by the user.
For more information, see App actions' guide.
Published on January 15, 2021
January 12, 2021
Updates to Goals API
We’re introducing three updates to our Goals API:
1. There’s a new goal type - revenue_forecast
. This type of goal allows users to track their revenue forecast.
2. Goals don’t need to have an end date. You can set up infinite, open-ended goals by setting end
to null
.
3. report_ids
array is now a part of the response of the Goals API. This array includes IDs of reports used in the Insights feature to highlight the goal’s progress over time. Every goal should have at least one report attached to it.
Published on January 12, 2021
January 7, 2021
Phone calls integration OAuth scope
CallLogs
endpoints have now been added to a new scope Phone calls integration which is available for OAuth apps. The scope will allow apps to enable advanced call integration features like logging call duration and other metadata and play call recordings inside Pipedrive.
You can find the following endpoints of the CallLogs
resource under this scope:
POST /callLogs
DELETE /callLogs/{id}
POST /callLogs/{id}/recordings
GET /callLogs
GET /callLogs/{id}
You can read more about the scopes and permission explanations here.
If you wish to update the scopes of an already approved or published app, be sure to learn how changing the scopes will affect your app's existing users.
Published on January 7, 2021
January 6, 2021
GET/itemSearch
now supports returning Leads
What will change?
GET /itemSearch
now supports returning Leads in related_items
for Organizations and Persons that are linked to it. When the search_for_related_items
for GET /itemSearch
is set to true
, the response will include up to 100 newest related Leads in addition to up to a 100 Deals for each found Person and Organization.
Published on January 6, 2021
January 4, 2021
Breaking change in GET /files
endpoint
What will change?
We are going to change the definition of the sort parameter of GET /files
endpoint. We’re going to allow sorting by 2 columns only (id
, update_time
) and restrict sorting by more than 1 column at the same time (e.g. field_name_1
ASC, field_name_2
DESC won’t work anymore).
Why?
We are optimising our sorting operations together with moving to a new service for files management.
Who is affected?
Anyone doing queries to GET /files
using sorting by file_type
.
Published on December 17, 2020
December 11, 2020
Bug fix in date
and datetime
fields
There was an issue with date
and datetime
fields, which affected Deals, Persons, Organizations, Products and Activities resources. When filtering by date
and/or datetime
with the operators <
, >
, <=
, >=
it might have returned rows with an empty date (0000-00-00
) and/or empty datetime (0000-00-00 00:00:00
). We made the server response more strict, which means that now when filtering the same way the rows with empty date will always be excluded.
The issue has now been fixed.
Please let us know if you have any questions by replying to the forum thread here.
Published on December 11, 2020
December 28, 2020
Removal of two endpoints from the /Users
resource
We have now deprecated and will be removing the following two endpoints from the Users
resource:
In case you are still using the above-mentioned API endpoints in your code or 3rd party app/integration, please remove any dependency on these endpoints by December 28, 2020.
Published on November 23, 2020
October 30, 2020
Leads OAuth scopes
Leads
endpoints have now been added to two new scopes which are available for OAuth apps.
You can find the endpoints of the Leads
resource under leads:read
and leads:full
scopes.
Endpoints in leads:full
scope:
POST /leads
GET /leads
GET /leads/{id}
PATCH /leads/{id}
DELETE /leads/{id}
GET /leadSources
POST /leadLabels
GET /leadLabels
PATCH /leadLabels/{id}
DELETE /leadLabels/{id}
Endpoints in leads:read
scope:
You can read more about the scopes and permission explanations here.
If you wish to update the scopes of an already approved or published app, be sure to learn how changing the scopes will affect your app's existing users.
Published on October 30, 2020
October 30, 2020
New logic for updating scopes on existing apps
Apps can now update their OAuth scopes without automatically having the app uninstalled for all existing users.
The process will now work as follows:
Apps (draft/private, unlisted and public) can update their scopes at any time.
When the scopes have been updated, existing users will receive a notification email letting them know of the change in scopes and asking them to reauthorize the app.
Apps that decide to update their scopes must be able to clearly direct users to reauthorize the app in the Marketplace. This must be done to allow users to use the app in its full capacity. The scopes change will not halt the app's functionality - the features built with previous scopes will continue working.
From the Marketplace side, the app listing will remain available and won’t be sent back into the app approval process. The scopes displayed in the installation screen of the app listing will be automatically updated to reflect the new scopes.
The user has the option to either accept or deny all scopes. Because of this, it's a good idea to build apps that only request scopes that are absolutely necessary for your particular use-case. You can see the list of available OAuth scopes here.
Published on October 30, 2020
October 27, 2020
Bug fix in GET /pipelines
endpoint
There were two issues with GET /pipelines
endpoint.
It ignored start
and limit
parameters when getting all pipelines, and in some cases for the more_items_in_collection
field an incorrect value was returned (true
instead of false
).
Both issues have now been fixed.
Please let us know if you have any questions by replying to the forum thread here.
Published on October 27, 2020
November 10, 2020
Breaking change in POST /deals
and PUT /deals/{id}
endpoints
Endpoints directly affected:
What will change?
In Pipedrive, admin users can set visibility groups and permission sets. Visibility groups are used to categorize users and dictate what entity they will be allowed to see. Permission sets dictate what actions the users in the account are able to perform. To see and set the visibility group of the entity through the API we have the visible_to
parameter.
If one tries to set the wrong visible_to
value when requesting POST /organizations
, PUT /organizations/{id}
, POST /persons
or PUT /persons/{id}
endpoints, they will get the 403
response code. We’re adding that same additional validation to POST /deals
and PUT /deals/{id}
endpoints.
Why?
POST /deals
and PUT /deals/{id}
endpoints don't currently return an error if an incorrect value is given to visible_to
parameter, instead the request is shown to be successful and it will ignore the data sent by the user.
Who is affected?
This change affects only non-admin type of users who belong to a permission set where the permission Can change visibility of items is turned off.
Published on October 13, 2020
October 20, 2020
Breaking change in /subscriptions/recurring
and /subscriptions/installment
endpoints
Endpoints directly affected:
What will change?
Instead of allowing to specify any random 3 character string as currency, the service will start checking if the specified currency is a real currency or a custom currency used in a company. Also, the service will start returning the error Unknown currency provided!
if the inserted currency is unknown.
You can use GET /currencies
endpoint to see a list of currencies accepted by Pipedrive as well as custom currencies a company might have created.
Why?
Users are able to use the “incorrect” currencies as parameters and it may cause issues.
Who is affected?
Anyone with functionality built on top of the previous behaviour might need to alter their code.
Published on October 6, 2020
September 21, 2020
New endpoints in products:full
scope
Products:full
scope now allows apps to have access to 2 new endpoints.
By selecting the products:full
scope, an app can now have access to the 2 following endpoints, which allow the app to add or remove followers from products:
You can read more about the scopes and permission explanations here.
If you wish to add or remove scopes of an already approved or published app, be sure to learn how changing the scopes will affect your app's existing users.
Published on September 21, 2020
September 21, 2020
Fix in POST /subscriptions/recurring
endpoint documentation
We had the payments
parameter marked as required in the documentation of POST /subscriptions/recurring
endpoint in our API Reference, but under the hood it is not a required parameter. We have now removed the required flag (a red asterisk) from the payments
parameter.
Published on September 21, 2020
August 7, 2020
New parameter in two Deals endpoints
We have added the new parameter expected_close_date
to the PUT /deals/{id}
and POST /deals
endpoints.
The expected_close_date
parameter allows you to change the date of when the Deal is expected to be marked as won.
Published on August 7, 2020
August 6, 2020
Introducing Subscriptions API
We have added a brand new Subscriptions
resource to our API which represents the Recurring Revenue feature inside Pipedrive.
Subscriptions represent the revenue that is occurring over time with payments either in set or varying amounts. Subscriptions have two types - installment and recurring. Installment Subscription occurs over time with payments in varying amounts and payment dates. Recurring Subscription occurs over fixed intervals of time with payments of the same amount.
The Subscriptions resource includes the following endpoints:
GET /subscriptions/{id}
GET /subscriptions/find/{dealId}
GET /subscriptions/{id}/payments
POST /subscriptions/recurring
POST /subscriptions/installment
PUT /subscriptions/recurring/{id}
PUT /subscriptions/installment/{id}
PUT /subscriptions/recurring/{id}/cancel
DELETE /subscriptions/{id}
To be able to use an endpoint using OAuth authorization, the endpoint needs to be added to a scope. We have added the endpoints of the Subscriptions
resource to our deals:read
and deals:full
scopes.
You can read more about the scopes and permission explanations here.
If you wish to update the scopes of an already approved or published app, be sure to learn how changing the scopes will affect your existing users.
Published on August 6, 2020
July 23, 2020
Introducing Leads API
We have added a brand new Leads resource to our Pipedrive API.
In the sales world, Leads are potential Deals that are stored separately in the Leads Inbox within Pipedrive.
The Leads resource allows you to get, create, update and delete Leads, Lead Labels and get Lead Sources.
In API requests, each Lead needs to be named (using the title
field) and be linked to either a Person or an Organization. Linking to either a Person or an Organization is required in order to keep all the information regarding Contacts in one part of Pipedrive, instead of separating it between Contacts and Leads Inbox, as it is crucial information in sales peoples' daily work. This way all the communication between the sales person and the contact can be found in one place (Person or Organization detail view in Pipedrive) through the entire sales cycle.
Leads can contain the same custom fields as the custom fields of a Deal. If the value of a custom field has been set for a Lead, it will appear in the response of the request.
The Leads resource includes the following endpoints:
GET /leads
GET /leads/{id}
GET /leadLabels
GET /leadLabels/{id}
GET /leadSources
POST /leads
POST /leadLabels
DELETE /leads/{id}
DELETE /leadLabels/{id}
PATCH /leads/{id}
PATCH /leadLabels/{id}
POST
and PATCH
requests made to the Leads endpoints must be done using content-type: application/json
.
Please note that the OAuth scope is currently not available for the Leads endpoints, but we are working to get it added.
Published on July 23, 2020
July 14, 2020
Improved protection of user data
We have now improved the security of user data.
What has changed?
When returning the User
object, the following API endpoints
will have all fields except for id
, name
and email
set to null
if the user is unverified in the company (which is always the case for the POST /users
endpoint).
This also affects endpoints of other entities such as Deals, Persons, Organizations, Notes, etc., which may contain related User objects.
Who is affected?
Anyone with functionality built on top of the previous behaviour, for example: anyone who strictly relies on the values in the response of the aforementioned endpoints and related webhooks.
The list of affected fields in User
endpoints:
phone: string
created: string (date)
modified: string (date)
default_currency: string
locale: string
lang: int
timezone_name: string
timezone_offset: string
signup_flow_variation: string
icon_url: string
The field lang
will return the default value of 1
.
Published on July 14, 2020
July 1, 2020
Removal of additional_data
and pagination
objects from 3 endpoints
What will change?
We have now deprecated and will be removing the additional_data
and pagination
objects on July 1, 2020 from the responses of the following Deal, Person and Organization endpoints.
Here is the list of 3 affected endpoints:
How the response body currently looks:
{
"success": true,
"data": [
007
],
"additional_data": {
"pagination": {
"start": 0,
"limit": 1,
"more_items_in_collection": false
}
}
}
Response body after the change:
{
"success": true,
"data": [
007
]
}
If your requests to those three endpoints also contain pagination related parameters limit
and start
we recommend removing those as they won’t serve their purpose any longer.
Who is affected?
Anyone with functionality built on top of the previous behaviour. For example, anyone who is strictly checking the shape of the response of the aforementioned 3 endpoints.
Published on May 25, 2020
April 23, 2020
New scopes for Goals and Teams
Goals help sales teams meet their sales targets and Teams allow sales people to form groups of users within the organization for more efficient management.
To be able to use an endpoint using OAuth authorization, the endpoint needs to be added to a scope. This is why we have added the endpoints of the Goals
and Teams
resources to our scopes.
You can find the endpoints of the Goals
resource under goals:read
and goals:full
scopes, and the endpoints of the Teams
resources under users:read
and admin
scopes.
You can read more about the scopes and permission explanations here.
If you wish to update the scopes of an already approved or published app, be sure to learn how changing the scopes will affect your existing users.
Published on April 23, 2020
April 15, 2020
New parameters added to /activities
POST
and PUT
endpoints
We have added four new parameters to POST /activities
and PUT /activities/{id}
endpoints:
location
Allows inserting the address of the activity.
public_description
Allows adding additional details about the activity that will be synced to your external calendar.
busy_flag
Allows setting the activity as “busy” or “free”.
attendees
Allows adding guests to the activity whether it is an existing Pipedrive contact or an external email address.
Published on April 15, 2020
March 31, 2021
Removal of the /*/find, /searchResults, and /searchResults/field endpoints, replaced by 6 new endpoints
What will change?
We have now deprecated and will soon be removing the following 6 API endpoints:
- GET /deals/find - Searches all deals by their title
- GET /persons/find - Searches all persons by their name
- GET /organizations/find - Searches all organizations by their name
- GET /products/find - Returns data about the products that were found.
- GET /searchResults - Searches all items or 1 item by all fields
- GET /searchResults/field - searches 1 item type by 1 field
We strongly advise you to avoid the use of these 6 deprecated API endpoints.
Why?
We are introducing 6 new endpoints:
The new Search API endpoints offer extended functionality over the old search API and have a unified future-proof response format. The extended functionality allows you to do complicated queries from several item types and fields at once.
For example you can use /v1/itemSearch?item_types=deal,person&fields=title,name,custom_fields&term=example
to search from all persons and deals by the person’s name, deal title and both items custom fields and order them by relevance.
The /*/search
endpoints are aliases for /v1/itemSearch?item_types=*
endpoint with narrower OAuth2 scopes for if you are a marketplace app owner and would like your app to only have read
access to specific item types instead of the full search scope.
Who is affected?
Anyone depending on the previously listed 6 deprecated endpoints in any way is affected. In case you are using the previously listed 6 deprecated API endpoints in your code or 3rd party app/integration, please remove any dependency on these endpoints as soon as possible, or by March 31, 2021 the latest. For additional help, check out new search API migration guide.
Published on April 8, 2020
May 31, 2020
Removal of the reference_activities_count
field
What will change?
We have now deprecated and will be removing the reference_activities_count
field on May 31, 2020 from
- the responses of the following Deal, Person and Organization endpoints
- the Deal, Person, and Organization related webhook payloads
Here is the list of 21 affected endpoints:
GET /deals
GET /deals/{id}
POST /deals
POST /deals/{id}/duplicate
POST /deals/{id}/participants
PUT /deals/{id}
PUT /deals/{id}/merge
GET /deals/{id}/participants
GET /deals/{id}/persons
GET /organizations
GET /organizations/{id}
GET /organizations/{id}/deals
GET /organizations/{id}/persons
POST /organizations
PUT /organizations/{id}
GET /persons
GET /persons/{id}
GET /persons/{id}/deals
POST /persons
PUT /persons/{id}
PUT /persons/{id}/merge
There will be no changes to any request body.
Why?
We are no longer updating that field. Until removal, the value of the field will always be 0
:
"reference_activities_count": 0
Who is affected?
Anyone with functionality built on top of the previous behaviour, for example, anyone who is strictly checking the shape of the response of the 21 endpoints and related webhooks.
Published on March 31, 2020
March 26, 2020
New parameters added to flow endpoints
We have added the new parameters all_changes
and items
to the following endpoints:
The all_changes
parameter allows you to choose whether to show custom field updates or not. The items
parameter is a comma-separated string for filtering out item-specific updates.
Published on March 26, 2020
March 24, 2020
New field added to custom field POST
endpoints
We have added a new address
field to the following endpoints:
The address
field is used to store addresses. You can read more about the types of custom fields here.
Published on March 24, 2020
March 4, 2020
New fields in Users GET /users/me
endpoint
We have added two new fields to the GET /users/me
endpoint. When getting the current user data, the output now contains the following fields:
company_country
company_industry
You can now see how the output will look like in the getting user data page.
Published on March 4, 2020
June 1, 2020
New parameter in OAuth /oauth/token
responses
What will change?
We have added a new parameter api_domain
to OAuth /oauth/token
responses.
For now, only the apps created on or after February 20, 2020 will see the new parameter in the OAuth /oauth/token
response.
On June 1, 2020, the code will automatically start sending the new parameter to all requests, i.e. apps created before February 20, 2020 will also start seeing the new parameter in the OAuth /oauth/token
response. If you are strictly checking the shape of the response, please update your code to take the new parameter into account.
Why?
Until now (and because we ask you to use https://companydomain.pipedrive.com
domains for making API requests), in order to find out the company_domain
, you had to get the OAuth tokens first, make a request to /users/me
endpoint and store it on your side. Also, the company_domain
can change so you had to make additional request to /users/me
every once in a while.
But with this change you do not have to do that anymore, because you will now receive up-to-date company_domain
every time you make the initial request to get the tokens or when you refresh a token.
The current response:
{
"access_token": "53:179:6317ef33a9fb0c4d604ce0695dad44a12bad44c9",
"token_type": "Bearer",
"expires_in": 3599,
"refresh_token": "53:179:5de81994d77491d22bc10eab3bc0810f84864297",
"scope": "base,deals:full,contacts:read"
}
The new response with the added api_domain
parameter:
{
"access_token": "53:179:6317ef33a9fb0c4d604ce0695dad44a12bad44c9",
"token_type": "Bearer",
"expires_in": 3599,
"refresh_token": "53:179:5de81994d77491d22bc10eab3bc0810f84864297",
"scope": "base,deals:full,contacts:read",
"api_domain": "https://mycompanydomain.pipedrive.com"
}
Who is affected?
Any app created before February 20, 2020 with functionality built on top of the previous behavior need to alter their code by June 1, 2020.
Any apps created on or after February 20, 2020 will already see the new parameter in the OAuth /oauth/token/
response and do not need to alter anything concerning this change.
Published on February 21, 2020
December 10, 2019
New Teams resource
We have added a brand new Teams
resource. Teams allow sales people to form groups of users within the organization for more efficient management.
The new Teams
resource includes the following endpoints:
Published on December 10, 2019
November 29, 2019
New Goals resource
We have added a brand new Goals
resource. Goals help sales teams meet their sales targets.
The new Goals
resource includes the following endpoints:
Published on November 29, 2019
October 17, 2019
New parameter in Notes POST
and PUT
endpoints
We have added a new parameter user_id
to the POST /notes
and PUT /notes/{id}
endpoints.
By inserting the ID of a user into the user_id
parameter when making requests against the following endpoints, you can now choose or change the author of a note:
For example, this user_id
parameter might come in handy when importing data to Pipedrive. Please keep in mind that only an admin can change the author.
Published on October 17, 2019
October 7, 2019
Breaking change in /searchResults
and /organizations/find
endpoints
Endpoints directly affected:
What will change?
When the /searchResults
and /organizations/find
endpoints return an organization with no details, the organization details field will return an empty object {}
instead of an empty string ""
.
Why?
This change will make endpoint responses more consistent by forcing the returned organization details field to always be an object.
The responses will be more consistent with results that do have organization details, which currently have the following format:
{
"org_address": "organization's address"
}
Who is affected?
Any integration with functionality built on top of the previous behavior might need to alter their code.
Published on September 23, 2019
September 17, 2019
Removal of access_level
feature
We have chosen to delete the access_level
feature due to it being an older and not fully implemented feature.
It was previously available in the following endpoints under Roles:
And there was a possibility to change it separately under Deal, Organization, Person, Product:
GET /deals/{id}/permittedUsers
GET /organizations/{id}/permittedUsers
GET /persons/{id}/permittedUsers
GET /products/{id}/permittedUsers
Published on September 17, 2019
September 3, 2019
Bugfix in /activities
endpoint
/activities
endpoint:
Additional information about pagination will now return correct values for the more_items_in_collection
when the related_objects=0
parameter is passed with the request.
Published on September 3, 2019
October 23, 2019
Breaking change in the JSON response structure of the Delete Person webhook
What?
We will be introducing a breaking change in the JSON response structure of the Delete Person webhook.
Currently the data for a Delete Person webhook is incomplete. For example, if a user has saved more than one email/phone nr on a Contact, then only the primary email/phone nr. will appear in the webhook data. Because of this, we will change the property type from a string to an array and add additional values (e.g. secondary email/phone nr) into the array when they are present.
When?
Changes will go live on October 23, 2019.
Why?
If our customers remove a Person, they can then use webhook data to delete the same information on their end. We would like to make sure when information is removed from Pipedrive, it can also be seamlessly removed from our customers’ databases.
Who is affected?
Anyone who has set up a webhook for a Person Delete event. If you or your team has built functionality on top of a previous response structure, then please make sure your code is changed accordingly.
Published on August 23, 2019
September 24, 2019
Websocket functionality deprecation
We are going to deprecate the websocket usage in client-nodejs for third-party developers https://github.com/pipedrive/client-nodejs/pull/94.
The current library will stop working on September 24, 2019. In case of any dependency affected by this deprecation, please keep in mind this is a breaking change. It is very urgent for you to update your library and migrate to using webhooks.
Published on July 30, 2019
August 15, 2019
Change in how future Activities behave
Endpoints directly affected:
What will change?
Currently, if future activities (due_date
and due_time
in the future) have been marked as done, those activities’ due_date
and due_time
have been overwritten with the marked_as_done_time
. This behaviour will be changed.
Starting from August 15, the due_date
and due_time
will remain as they were initially set, different from the marked_as_done_time
.
Why?
We are working on improving Pipedrive’s integrations with external calendars and this is a necessary change. Overall, this was an unexpected behaviour and we are bringing it into line with how calendars usually behave.
Who is affected?
Anyone creating statistics based on activities.
Anyone marking future activities as done.
If there is functionality built on top of the previous behaviour, it will have to be altered.
Published on July 15, 2019
July 5, 2019
Breaking change in PUT /activities/{id}
endpoint
There will be a breaking change for the PUT /activities/{id}
endpoint.
Starting July 5th, in order to reconcile with other item PUT
endpoints of our API, the endpoint will start directing to the DELETE /activities/{id}
endpoint when performing a soft delete by changing active_flag: 0
.
Published on June 25, 2019
July 1, 2019
Akamai WAP implementation
In order to provide a more secure service to our customers, Pipedrive is in the process of implementing Akamai WAP (Web Application Protector). The implementation of this tool ensures that malicious requests will be blocked.
Why are we telling you this?
In the implementation phase we are eliminating all false positives from the system to ensure that legitimate requests will not be blocked. If you happen to notice that your request is blocked and receives 403 error, please contact us and we can investigate why this occurred.
Published on June 17, 2019
June 4, 2019
New endpoint in Filters resource
We have added a new GET /filters/helpers
endpoint to the Filters
resource.
The new endpoint allows you to see the all the possible operators and their meanings for creating conditions
in order to either add or update a Filter
.
Here is a tutorial showing how to add a new Filter using the GET /filters/helpers
endpoint.
Published on June 4, 2019
May 30, 2019
New endpoint in Deals resource
We have added a new GET /deals/summary
endpoint to Deals
resource.
The new endpoint allows you to see the summary of all the Deals in one company. You can customize the response of the summary with the following parameters: status
, filter_id
, user_id
, stage_id
. Here is an example of one company's Deals summary without specifying any parameters:
{
"success": true,
"data": {
"values_total": {
"USD": {
"value": 201.99,
"count": 91,
"value_converted": 201.99,
"value_formatted": "201,99 $",
"value_converted_formatted": "201,99 $"
}
},
"weighted_values_total": {
"USD": {
"value": 201.99,
"count": 91,
"value_formatted": "201,99 $"
}
},
"total_count": 91,
"total_currency_converted_value": 201.99,
"total_weighted_currency_converted_value": 201.99,
"total_currency_converted_value_formatted": "201,99 $",
"total_weighted_currency_converted_value_formatted": "201,99 $"
}
}
Published on May 30, 2019
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
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
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
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 22, 2019
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
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
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
February 11, 2019
Removal of permissionSetAssignments
endpoints of the Users resource
We have removed the following endpoints of the Users resource:
GET
/users/{id}/permissionSetAssignmentsPOST
/users/{id}/permissionSetAssignmentsDELETE
/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 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
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 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
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):
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
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
December 21, 2018
Deprecation of permissionSetAssignments
endpoints of the Users resource
We will deprecate the following endpoints of the Users resource:
GET
/users/{id}/permissionSetAssignmentsPOST
/users/{id}/permissionSetAssignmentsDELETE
/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 November 21, 2018
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:
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
Updated about 18 hours ago