Undocumented breaking API change (29th Mar)

We have been using the Pipedrive API products and deals endpoints for some months now for both updating and creating new records. On March 29th, our integrations broke without warning.

It appears that it is now not possible to update a single option custom field using string of the value, instead the associated key id for that option must be provided. As an example:

Previous Code :

$headers = New-Object “System.Collections.Generic.Dictionary[[String],[String]]”
$headers.Add(“Content-Type”, “application/json”)
$body = “{"59fb458ceb385436f1988826cf0535608980eec6”: "Sent"}"
$concat = “https://api.pipedrive.com/v1/products/” + $id + “?api_token=[[token]]”
try {
$PutResponse = Invoke-RestMethod $concat -Method ‘PUT’ -Headers $headers -Body $body …

This code ran for months without issue (200 OK response) but suddenly returns

Invoke-RestMethod : The remote server returned an error: (422) Unprocessable Entity.|

At line:9 char:16|
+ ... tResponse = Invoke-RestMethod $concatta -Method 'PUT' -Headers $heade ...|
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebException|
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand|

The same occurs on Postman, and there is record in history of the previous method being successful.

Postman error :

“success”: false,
“error”: “Expected ‘number’ as value for single option custom field”,
“error_info”: “Please check developers.pipedrive.com for more information about Pipedrive API.”,
“data”: null,
“additional_data”: null

New working code:

$headers = New-Object “System.Collections.Generic.Dictionary[[String],[String]]”
$headers.Add(“Content-Type”, “application/json”)
$body = “{"59fb458ceb385436f1988826cf0535608980eec6”: "981"}"
$concatta = “https://api.pipedrive.com/v1/products/” + $id + “?api_token=[[token]]”
try {
$PutResponse = Invoke-RestMethod $concat -Method ‘PUT’ -Headers $headers -Body $body …

where “981” is the id representing the “Sent” value.

From what I can see, this appears to be an undocumented change in how the Pipedrive API functions.
Is there documentation for this change? Is this change intended?

Please advise :sunglasses:


Another dev here, who created a CRM integration to our system. It is an undocumented breaking change, and when I contacted the customer support, they said that using direct enum values (instead of ids) was not official part of documentation and therefore they just removed it.
It caused our integration to flip.

We then reworked our integration in such a way, that it fetches fields and enum values first and then maps them to ids in a separate function.

Hey @sybbear,

We have reworked ours in a similar way and it is working again. Differently to you, Support actually told me that this isn’t how it ever worked and that they hadn’t made a change at all. I made this thread in response to hopefully get it documented somewhere.

Sorry to hear you also went through this issue, but glad it’s sorted for you now.

I see! Likewise, good that you resolved.

As for the Pipedrive’s reply, I can tell 100% our integration has worked for months using direct enum values. Hopefully they can sort out their communication issues and stop pushing breaking changes in the API.

If APIs are continuously broken and unpredictable, while we use them for business-critical operations and pay for them, then it might be a time soon to find a new service provider. We just can’t be fixing our integration every other week and spending hours on customer support. That’s not how APIs are supposed to work. It’s just the truth.

1 Like

Hello, @VColl and @sybbear! :wave:

We apologize for the inconvenience this has caused!

Indeed, updating the single and/or multiple option fields’ values for products works by supplying the ID of the single/multiple option. The goal of this is to ensure data quality and expected behavior when updating the values.

We are working on including this information into our Updating custom fields’ values tutorial in our Developer Documentation.