PermissionSets API breaking changes

UPDATE (July 23, 2021) : Based on your feedback and to give you more time to align with our API changes, we’ve decided to postpone the breaking changes to our PermissionSets API to September 1, 2021 . See the announcement for more.

Effective from: July 26, 2021

What is going to change?

  1. The Permission Set ID format will be changed from integer to UUID (universally unique identifier) string. This means that the current IDs will be replaced with new values both in the endpoint path and the response body for the following three endpoints:
  1. The response of GET /v1/permissionSets/:id/assignments will no longer include the id field per assignment. An assignment is an object which currently includes the following fields
  • id (which will be removed)
  • user_id
  • permission_set_id
  • name (the name of the PermissionSet)
  1. Permission Set objects returned from GET /v1/permissionSets and GET /v1/permissionSets/:id will temporarily (for the next 2 months) have an additional field old_id of type integer, which will contain the old ID value

  2. Permission Set Assignment objects returned from GET /v1/permissionSets/:id/assignments will temporarily (for the next 2 months) have an additional field permission_set_id_old of type integer, which will contain the old Permission Set ID value

See the full post in our Changelog.

Hi Elina - I am the company manager of a small business and get these emails. Can you please also include some explanation of what this means in simpler non developer terms. I have no idea of the significance from reading your email above. Thank you Craig

Hi @CraigHarris

The upcoming change means that in case one has built a custom integration using our PermissionSets API and store permission sets in their systems now need to change the type of and re-map their permission set IDs (from numeric to new UUID - universally unique identifier)

If you are simply using our Pipedrive web app and have not built (or let a developer build it for you) any custom integrations using code and development, then you should have nothing to worry about. But if you have had someone build a custom integration to enhance your Pipedrive experience and you are using it, then please forward the change information to this person.

I hope this helps!

1 Like

Thank you Riin - that makes more sense. It would be appreciated if the emails from the development team that I presume go to all admin are prefaced by something that makes more sense to non technical people just so we know whether it needs to be acted upon or not.

We are using the Pipedrive web interface so I guess that is the app you are talking about. We don’t yet use standard integrations with Xero, Asana or other tools we use, so I assume we are in the clear.

1 Like

UPDATE (July 23, 2021) : Based on your feedback and to give you more time to align with our API changes, we’ve decided to postpone the breaking changes to our PermissionSets API to September 1, 2021. See the announcement for more.


I’m using 2 integrations, Zapier & Import2 but I’m not sure this is using this permission sets as I cannot retrieve this in these 2 tools. In order to be sure this change will not endanger my automations, can you give me feedback what I should look after or change to make sure as of 1st of September this keeps on functioning.


I am currently using the attached XML file for a CRM Integration with a Hosted Telephone System.

Please can you confirm what edits I need to do in the XML file to make sure the integration can work with the new API changes from Pipedrive?

<?xml version="1.0"?> data.items.item.phones [[CreateContactName]] [Number] [[InboundCallText]] [[MissedCallText]] [[OutboundCallText]] [[NotAnsweredOutboundCallText]] Call [Contact::ContactID] 1 0 [CRMUserID] [DealID]

Kind regards,


We currently use an integration with MissiveApp, will this be updated automatically as it’s not custom built for us? Thanks

Hi @els.costers, thanks for reaching out! This change is done in the back end of how the integrations work on their own; the app needs to make sure it is compatible with the change done inside Pipedrive’s API. If all is solved properly, your automations should not be affected.

Hi @Georgeashley, I’ve asked one of our developers to check over the XML you provided. They didn’t spot anything related to the PermissionSets endpoints that will be affected by the upcoming change in this code.
These changes will affect your integration if you check the responses of the requests strictly or you rely on the Permission Set ID (first change noted in the original post, where we state that the integer will change to UUID format). Hope this helps :slight_smile:

Hi @DonnaH, this change should be done by the marketplace apps automatically without any action required from you :slight_smile:

1 Like

Hi Elina,

The problem we are still having is Call Journaling from the phone system into Pipedrive.

Please can you confirm if there is a method in the Pipedrive API to search for an agent based upon their telephone number?

Kind regards,



George Ashley​

Sales & Operations Manager

image275393.png 01252 241000 | image064466.png 01252 241020

image868080.png | image119331.png

Centaur House, Ancells Business Park , Fleet , GU51 2UJ

image991427.png Book a meeting with me




Intouch Communications Ltd accepts no liability for the content of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company.

Hey Guys, we had a tech person come in to set up all of our automations who we no longer have at the moment.

I’m wondering now if these are going to effect our current integrations.

We have integrations through Zapier, Schedule Once, & Aloware.

The automations just move calls booked inside pipedrive & automatically add notes from Aloware / call recordings to each deal we have.

We also have all of our leads automatically populate to Pipedrive.

Please let m know if this is something we should be concerned with

Hi @Georgeashley, sorry for the late reply, missed your post somehow.
Can you give me more details on how your case is connected to the change in PermissionSets endpoints?
In general, for searching via the API you can use the itemSearch endpoints or search endpoint related to main resource.

Hi @Sarahmoloney, the change in the API should be directly handled by the apps that you are using. In general, if you have some custom coding done for your automation, we cannot ensure that it will continue to work with any change being done to our API, as this should be maintained by the code/integration/app owner. In the case that you described, it’d seem that all should continue to work as-is.

Thank you for the response, how do I find out if it would effect it or not so I am prepared?

Thank you

Hi @Sarahmoloney
Do you happen to know or are you able to find out if any custom coding was done by the tech person you had before?
If you had any custom code done, then they should be checked against these following as we don’t support custom code reviews at Pipedrive.
If you haven’t had any custom code done, then your automations should not be affected as this change is rather general.

Who is affected?

All consumers of the listed API endpoints are affected in case they

  • specifically expect Permission Set ID to be an integer
  • rely on the removed Permission Set Assignment id field