BROKEN Endpoint Test for Update Person on API Reference Web Page

I think that the Pipedrive API Reference web page endpoint testing functionality, for the procedure to UPDATE a PERSON, appears to be broken.

The web page URL that I’m writing about is:!/Persons/put_persons_id

I’ve entered a valid TOKEN… and my token does work for other APIs like the GET PERSON DETAILS API call.

I’ve entered a valid Person id number … eg 10149 … for a Person that is added to our Pipedrive Persons collection and which can be edited through web access to Pipedrive account. Also, I can successfully use the GET PERSON DETAILS API to get details for that person. So Person id is valid.

I enter a new name for the Person like “joe smith”

Then I hit the ENDPOINT button … but it returns error 400.

When I look at the REQUEST that the web page generated, the BODY looks wrong.

The HTTP BODY is just raw text with the Person id that was entered:


I would have expected the HTTP BODY to be something more like:

{data: {“id”:10149,“name”:“joe smith”}}

Or maybe:

{“id”:10149,“name”:“joe smith”}

For anyone else, does the UPDATE PERSON API endpoint test on the API References web page work for you?

And along those same lines, does anyone maybe know what the HTTP HEADERS and HTTP BODY might need to be for a working example for an UPDATE PERSON API request?

I ask this that because I am working in HTTP … not PHP … but the pipedive tutorial for updating a person is in PHP … and also the tutorial does not show the underlying HTTP HEADERS and HTTP BODY … and so I’m hoping to see/learn a valid HTTP configuration for a UPDATE PERSON API request. Also, it would be great if that UPDATE PERSON tutorial was edited to ADD the HTTP HEADERS and HTTP BODY for a valid working API call.

If anyone responds – a Big Thank You ahead of time!!!

Yes, the web page endpoint test for Person Update does appear to be broken.

Yes, the tutorial for the Person Update API does appear to have an inaccurate specification of what API will work.

A HTTP HEADER payload that does work is:
content-type: application/json

A HTTP BODY payload that does work is:
{“name”: “joe smith”}

The web page appears to be using the following incorrect HTTP HEADERS:
accept: application/json
content-type: application/x-www-form-urlencoded

The web page also appears to be using the following incorrect HTTP BODY:

Hope this helps someone else.

Hi @styleitalia,

Thank you for bringing this to our attention. We’re looking into it and will try to have it resolved quickly.

This issue is resolved.

@David I think this is also the case for the Add a participant to a deal endpoint.