Custom fields API regression

API
1

Hi,

We are having a regression regarding the API to update custom fields.

curl --location --request PUT 'https://api.pipedrive.com/v1/dealFields/12485?api_token=APITOKENAPITOKENAPITOKENAPITOKENAPITOKENAPITOKENAPITOKENAPITOKENAPITOKENAPITOKEN' \
--header 'Cookie: __cf_bm=SOMEVALUE=' \
--form 'options[0]['\''label'\'']="testApiFieldNewValue"'

The suggestion has been sent by the support (who refusing to help at this point) to switch to JSON it does not work either (unlike the user mentioned below).

Even if it worked, we are using a PHP wrapper that doesn’t let us switch easily how data is sent. devio/pipedrive - Packagist

Other elements:

Like this users we haven’t changed anything in our code. It would seem fair that the compatibility should be maintained Pipedrive side, not by patching on our sides depending on mood swings.

Thanks,

2

Hi,

unfortunately the example you posted is using an undocumented behavior which was never officially supported by the Pipedrive API. The API officially supports only application/json format of request body which is documented for a long time in the endpoint description.

Correct way to call the endpoint is would look like

curl --location --request PUT 'https://api.pipedrive.com/v1/dealFields/12486?api_token=<TOKEN>' \
--header 'Content-Type: application/json' \
--data '{
  "options": "[{\"label\":\"testApiFieldNewValue\"}]"
}'

What you can do:

  • ask the maintainer of the mentioned PHP Wrapper to update their package
  • switch to official Pipedrive PHP SDK (see example below)
  • can you also please provide the request which is not working for you after switching to JSON for further analysis?

I understand your struggle with the recent change in behavior of the API endpoint. However we can only support and maintain compatibility for what was intended to be used.
We offer a detailed feed of upcoming changes with at least a 2 months guaranteed compatibility before a breaking change to any of the officially supported (documented) behavior.
Often we issue also warnings for upcoming changes in undocumented behavior but we were unfortunately not aware of this case being used.

Example of changing Enum values with Official PHP SDK (will overwrite all values)

<?php

use Pipedrive\Configuration;

require_once('./vendor/autoload.php');


$config = (new Pipedrive\Configuration())->setApiKey('api_token', 'TOKEN');

$apiInstance = new Pipedrive\Api\DealFieldsApi(
    new GuzzleHttp\Client(),
    $config
);

try {
    $updateRequest = new \Pipedrive\Model\FieldUpdateRequest(['options' => "[{\"label\":\"testApiFieldNewValue\"}]"]);
    $result = $apiInstance->updateDealField(12486, $updateRequest);
    echo '<pre>';
    print_r($result);
    echo '</pre>';
} catch (Exception $e) {
    echo 'Exception when calling updateDealField: ', $e->getMessage(), PHP_EOL;
}

?>
1 Like
3

The PHP Wrapper relying on the undocumented behavior has three times the number of installs of your official SDK.

Why? Because it also seems three times older.

My two cents: it was very convenient at the time to have people open sourcing their work when you did not care to release your own wrapper. It could be nice to just consider breaking change impacting them.