and data is
36bf501ebe475968893ea586106f2f8a5d4dd22f=%D7%91%D7%93%D7%99%D7%A7%D7%94
and this is the result
{“success”:false,“error”:“Bad request”,“error_info”:“Please check developers.pipedrive.com for more information about Pipedrive API.”,“data”:null,“additional_data”:null}
That is either a Multiple Option or Single Option Field (it’s dependent on whether or not it allows multiple options so I can tell that the Body here is incorrect. For these types of Fields, there’s already defined Values/Options for this Field which are Integers.
You can use Pipedrive API v1 Reference to find out the Value IDs available for this Field and then use them when updating the Fields.
I’ve got exactly the same problem. I’m also trying to update a MultipleOption Field on a deal. However, even when using the option id in the body of the PUT request I can’t get it to work.
I don’t know if that’s also the case for Viki, but in my case, that PUT Request is triggered by a deal.added webhook message sent from pipedrive to another piece of software.
Endpoint: /deals/{id}
What I’ve tried so far:
Sending a stringified int id in the body:
{“9ad111c18fec4addc2130a29a3bb597088931897”: “235”}
Sending it as a JSON int:
{“9ad111c18fec4addc2130a29a3bb597088931897”: 235}
Both resulted in a “Bad Request” response.
Could that be a timing issue, e.g. sending the PUT request to soon after receiving the webhook message?
this is a single option field but it has defined values and we tried to set one of these values.
can you please send an example of how we should find out the value ids? i cant find it, and can we get the value itself with the value id?
If you use the GET /dealFields (or whichever Fields you’re looking for) endpoint, you’ll see the IDs of all your (Deal) Fields, for Single and Multiple Option Fields you’ll see the Values and IDs for all of the options you have for those Fields as well:
So it needs to be what I already tried. I’ll try to increase the time between receiving the webhook deal.added message and the PUT request then. Thankfully I’ve already implemented the last part in an async function and increasing the wait time is trivial. I’ll report back if that changes anything. Thank you David.
Well, unfortunately increasing the delay to 60 seconds between receiving the deal.added webhook message and sending the PUT Request didn’t help.
I’ll try to capture the outgoing PUT Request in full and post it here for further troubleshooting.
@David ist there anything missing from the request or any obvious errors that you can see?
edit: I believe I’ve found the problem. Our API client implementation would automatically marshall a map to json, but I had an extra step to marshall the body to json beforehand. So I had doubled the json marshalling for the request body, which would explain the base64 encoded body above.
I’ll report back if it works.
Just wanted to let you guys know, that making sure to marshal the Request object only once solved my problem. No ‘Bad Request’ responses since deploying the new version of our app with that bugfix.