I’m transitioning our use of the pipedrive REST api from v1/persons/find to v1/persons/search and was hoping to get some confirmation from the dev team on an issue we experienced to see if our workaround will still be needed
According to the openapi description of the API
the success key in the json response should always be a Boolean value.
Around June 10, 2019 we encountered an issue where this success field was returning with a ‘Disallowed’ value so we had to modify our data type from Boolean to String to account for this.
In migrating to this new search api, I’m hoping you can confirm whether or not we might encounter this issue again. Ie, will the success key in the json response be ‘true’, ‘false’, null, OR should we also account for potential responses like disallowed.
Thanks in Advance,
Can you give us more specific info about when did you see this ‘Disallowed’ value happening and was this only once? Currently we support the success key being in ‘true’ or ‘false’, but i’d like look more into this case.
Thanks Elina. I’ve been investigating this issue in some detail and have more information.
It looks like it’s not the success field having this trouble, it’s that whatever we are passing into the activities create method
Here is an example POST request we are sending along. NOTE: I’ve replaced/removed any A-Z content but left in characters that might be at issue.
POST https://api.pipedrive.com/v1/activities?api_token=<valid_api_token> HTTP/1.1
Content-Type: application/x-www-form-urlencoded; charset=utf-8
person_id=####&deal_id=####&subject=Text Message (###) ###-####¬e=<p>Outbound 05/17/21 04:50 PM ()</p>
<p>! '. ? ' ! ' , ' & , & ! ?
---> END HTTP ( 818-byte body)
As you can see from the following response, we are getting 200 response with content-type: text/html back. It’s not clear from the message what the disallowed key is in the message. If the content is incorrect, I would think a response should be an error json response like the developer docs mention at https://pipedrive.readme.io/docs/core-api-concepts-responses
<--- HTTP/1.1 200 OK (373)
access-control-expose-headers: X-RateLimit-Remaining, X-RateLimit-Limit, X-RateLimit-Reset
content-type: text/html; charset=UTF-8
date: Mon, 17 May 2021 20:50:26 GMT
x-xss-protection: 1; mode=block
Disallowed Key Characters.
<--- END HTTP ( 26-byte body)
Thanks for any insight you can pass my way
It looks like the
content-type that you are sending doesn’t like the
& formatting of the parameters in the body of the request. Can you try sending the request with
We also had a similar discussion on the topic here. Let me know if it helped! In any case, the success response to our requests should either be ‘true’ or ‘false’.
Thanks, we moved our API to use application/json rather than form encoded and are no longer seeing this Disallowed issue