Confirmation of the Json Success field Response Type

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,

Hey @Jacob_Danner

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<valid_api_token> HTTP/1.1
---> Headers
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Content-Length: 818
---> Body
person_id=####&deal_id=####&subject=Text Message (###) ###-####&note=<p>Outbound 05/17/21 04:50 PM  ()</p>
<p>! '. ? ' ! ' , ' & , & ! ?

<a href="[obfuscated_url]">[IMAGE]</a>

---> 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

<--- HTTP/1.1 200 OK (373)
<--- Headers
access-control-expose-headers: X-RateLimit-Remaining, X-RateLimit-Limit, X-RateLimit-Reset
alt-svc: ...
badi: ...
cache-control: no-cache
cf-cache-status: DYNAMIC
cf-ray: 650fb7cf8c6d39c0-SEA
cf-request-id: 0a1db135b0000039c068992000000001
connection: keep-alive
content-type: text/html; charset=UTF-8
date: Mon, 17 May 2021 20:50:26 GMT
expect-ct: ...
server: cloudflare
set-cookie: ...
transfer-encoding: chunked
vary: Accept-Encoding
x-content-type-options: nosniff
x-correlation-id: a59dcdcb-2943-4600-a5c5-7d5d20c82776
x-daily-requests-left: 9937
x-ratelimit-limit: 40
x-ratelimit-remaining: 36
x-ratelimit-reset: 2
x-xss-protection: 1; mode=block
<---  Body
Disallowed Key Characters.
<--- END HTTP ( 26-byte body)

Thanks for any insight you can pass my way :smiley:

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 content-type: application/json?
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

1 Like