I’m looking for a way to get a list of entity fields (Deal, Person or Organization) which can be filled when creating one of these entities in Pipedrive via the API. The reason for that is that in my app I’ve got an interface which allows the customer to select which entity fields can be filled with data when such an entity is sent for creation in Pipedrive.
To make it a bit more clear, let’s take the Deal for example. I want to expose most of the standard fields, like deal title, value, expected close date, etc., but I want to hide fields which shouldn’t be filled - like next activity date, last email sent, etc.
Now, I thought about checking the “edit_flag”, but that gives me only the list of custom fields. And the standard fields like deal title, value and status all have the “edit_flag” set to false. So after some research I think I found a good rule for listing these fields - either the “edit_flag” or the “bulk_edit_allowed” flag should be set to true, and the key shouldn’t end with “_id”.
So, can anybody confirm that this will give me a list of fields which can be filled with data before creation? Also, can that list of fields be used when updating as well, or that should use a different rule?
Hi there,
Just to understand better, can you give me an example of a field of a deal (or another resource) that you want to fill, and that is not listed on the reference page and it’s not a custom field?
Let’s say I have made two custom fields in a deal - “source” and “category”. Then I want to create a deal with the following data:
{
“title”:“Sample deal”,
“value”:300,
“source”:“direct”,
“category”:“campaign”
}
What I need is a way to get a list of the fields which can be filled (or rather, which make sense to be filled) before creation - that is, get a list containing [title, value, source, category] (again, this is just for example). I suppose I can get that by listing all custom fields + picking what I need from the list of fields on the ref page, but I wanted to know if there’s a rule I can use to filter them from the GET /dealFields API response, instead of hardcoding the field keys.
It could be that you found out a workaround to list these fields programmatically, but I honestly don’t know if that’s the case. So if you go that route, you do that at your own risk
It’s probably better to simply rely on the fields listed in the reference + adding your custom fields.
