Contents
When to use custom fields in the API?
These 40-character custom fields (for example dcf558aac1ae4e8c4f849ba5e668430d8df9be12) are not shown in our API Reference as they differ for each Pipedrive account, but they can be seen in the API requests and responses as well as used in the requests when adding new items, or updating existing ones.
How are custom fields created in contact sync?
These fields are similar to the default Pipedrive fields as they have a field API key that follows the syntax of all default Pipedrive API keys (field name, with an underscore replacing each space), unlike user-generated custom fields. See below the 5 custom fields created by Contact Sync:
Where can I find the API key for a field?
You can’t rename the reference of the custom field (the field API key), but you can rename the name of a custom field that’s visible to the User. Inside Pipedrive, you can find the API key of a field by going to Settings > Data fields and choosing the entity (Deal/Person/Organization/Product).
Where do I find custom fields in Pipedrive?
All custom fields are referenced to as randomly generated 40-character hashes in the dataset, for example dcf558aac1ae4e8c4f849ba5e668430d8df9be12 – it may look like our office cat walked across the laptop, but this actually is a key for a custom field in our API dataset.
Why does the search API not support the fields option?
The search API does not technically support these query options because the behavior is expressed in the POST body. For all these entity types, specifying the fields property reduces the number of properties returned in the response, optimizing the payload over the wire.
Are there any use cases for the search API?
The search API does not support aggregations for message, event, site or drive. Customizations in SharePoint search, such as a custom search schema or result sources, can interfere with the operation of the Microsoft Search API. Learn more about a few key use cases: