Changes to "enum" options id's?

Hello People! Here in our org, we have some custom fields of field_type:“enum” and we have some integration with other systems using webhooks and GET endpoints.

Today I’ve found an intriguing difference in some of our deals, some of them (I suspect the newer ones) have integer id’s for options of the enum fields, while other deals have string id’s for the same options and fields (used to be all strings), leading for some difference like this in endpoint answers and breaking our integrations
“7ca895c22242a4f7ce0f227ea477f9d207144c51”: “1116”,

This is related to any known update in Pipedrive structure? Didn’t found anything on the changelog.


Hey @guilhermefbar
Thanks for bringing this to our attention and also checking the changelog in prior.

Did you start noticing it after a particular point in time? If so, please share the timeframe, it will help in narrowing it down.

Could you also share the x-correlation-id present in the responses of these API calls?

Hello! I’ve noticed really yesterday, but still didn’t got time to look at past and find the moment

but a call on GET api/v1/deals/12592 gives me str ids:
x-correlation-id: 57d9efc2-00c2-4c8c-9ff9-961043a55a8e

a call on GET api/v1/deals/19145 gives me int ids:
x-correlation-id: 6117dfe3-edf0-4707-b821-1c1f65c6e882

and a call on GET /api/v1/dealFields gives me int ids on all enum field options:

x-correlation-id: f486a54c-eea1-4530-a705-b6d30e67ff1c

We noticed this starting on Feb 9 and it looks like they have reverted back to strings as of an hour ago, or so.

Hey @guilhermefbar & @p13guy
Thanks for sharing the relevant details. I have reached out to engineering to understand the cause.

I would suggest type casting for now but I realize that such field type changes are not normal. Let me get to the bottom of this

Thanks for being patient. This was caused due to a minor inconsistency on Pipedrive’s side. This should be fixed now.