Changelogs
We regularly enhance Zoho CRM APIs with new features to suit your evolving business requirements. The following changelogs detail all significant changes introduced in version 7 of Zoho CRM APIs.
Navigating through code samples: In each of the code samples, newly introduced keys are presented in green, existing keys that are updated are presented in orange, and keys that are removed are presented in red.
Version 7
The Zoho CRM APIs with updates specific to V7 are listed below.
- Modules API
- From V7, a Zia insights module will be created automatically whenever you enable any Zia features for a specific module. You can fetch the list of these Zia insights modules using the Modules API.
- Zia features : Field Prediction, Churn Prediction, NBX, Recommendation, Call Transcription, Best Time for Call, Best Time for Mail, Owner Recommendation, Vision, Best Time for Notes, and Best Mode to Contact.
- When you enable Zia features for a module, a corresponding Zia Insights module will be created, from V7.
Zia features : Field Prediction, Churn Prediction, NBX, Recommendation, Call Transcription, Best Time for Call, Best Time for Mail, Owner Recommendation, Vision, Best Time for Notes, and Best Mode to Contact.
To see the fields available within the created Zia Insights module, use the GET - Fields Metadata API
Note : Use the corresponding Zia insight module's API name in the "module" parameter. Example : /settings/fields?module=Leads_Insights__s
- A new "layout_associations" JSON array key is introduced in the response of the GET - Fields Metadata API from V7, representing the layouts with which the fields are associated in a module.
- When you enable Zia features for a module, a corresponding Zia Insights module will be created, from V7.
- While fetching a particular layout using its unique ID in a module, the "subform_properties" JSON object in the response of the GET - Layouts API represents whether any field is pinned in the subform.Note: This feature is currently in "Early Access." Contact the support team at support@zohocrm.com to request access.
- The "mode" key will be listed in the GET - Layouts API, representing the section's mode in a layout.
- Possible values
- All modules except "Events" :default_create, quick_create, and business_card.
- Events module : create, view, and quick_view.
- Subform: create and view.
- Wizard : create
- From V7, the category key has been changed to type__s.
- The structure for the values has been changed. For example, "category":"regular_user" to "type__s": Regular User. An underscore(_) between values has been replaced with a space.
- The Lite User value in the type__s key has been changed to Team User from V7.
- Related List API
Introduced in V7, the "status" key for each related list represents its visibility in the module.
Possible Values : visible, user_hidden, and scheduled_for_deletion.
- Territories API
- From V7, You can retrieve a maximum of 2000 records in a single API call, using the Territories API. The maximum value of "per_page" key has been increased from 200 to 2000.
From V7 onwards, the "include" parameter is introduced to retrieve territory specific criteria rules. Possible Values: lead_rule_criteria, account_rule_criteria, and deal_rule_criteria in a comma separated value.
Note : In V7 GET Territories API, the lead_rule_criteria, account_rule_criteria, and deal_rule_criteria will not be displayed unless you specify them to the include parameter.
The "api_name" key is introduced from V7 to represent the API name of a territory.
- From v7, the "used_count" JSON object key is introduced within the "component" JSON object to denote the feature's usage count for your edition.
- From V7, all custom field datatypes are grouped together under a single "Custom Field" component. Each specific datatype (like text, integer and so on) is represented as a separate component within this main "Custom Field" component in the GET - Features API's response.
- From V7 onwards, the "Personal Health Field" will be included in the response of the GET - Features API.
- The value of the "code" key in the response of the Mass Convert Lead API has been changed from "SUCCESS" to "SCHEDULED".
- In the GET - Files API, if you do not pass the "id" parameter, the system will return an "HTTP 400 - REQUIRED_PARAM_MISSING" error response from V7. If you specify an invalid ID in the "id" parameter, the response will be "HTTP 204 - NO_CONTENT".
- Blueprint API
In a blueprint record, the "current_picklist" JSON object is introduced in the GET - Blueprint API response from V7, specifies the details of the current picklist option.
The current_picklist includes :
- colour_code (string): Represents the hex color code of the current picklist option.
- id (string): Represents the unique ID of the current picklist option.
- value (string): Represent the value of the picklist option.
- In the User Groups API, you can do criteria-based searches for user groups , using the "filters" (singular and multiple filters) parameter introduced from V7.
- Using the Associated Groups of a User API, from V7, the "include" parameter is introduced to know the sources available in a group a user is associated with. Supported value is sources.
- If the Create Bulk Read API request has more than 200,000 records to export in a module, the "next_page_token" key will be present in the Get the Status of the Bulk Read Job's response from V7.
- Use the next_page_token's value received in the response of the Get the Status of the Bulk Read Job API to fetch the next set of records by passing the value to the "page_token" key (introduced from V7 onwards) using a separate Create Bulk Read job API. Repeat this process until all records are retrieved.
- The field limit in the SELECT column of a query has been increased from 50 to 500.
- The CVID support has been given from V7.
- You can retrieve the metadata of the fields specified in the SELECT column by using the include_meta key.
- ORDER BY clause : A maximum of 10 fields can be given in the ORDER BY clause.
- GROUP BY clause : A maximum of four fields can be given in the GROUP BY clause.
- Aggregate Fields : A maximum of five aggregate fields can be given in a query.
- The value limit for the in and not in operators has been increased from 50 to 100.
- You can fetch territory information from a module by including the territory field API name in the SELECT column.
- The Full Name will be retrieved based on the current user's display name pattern, as set in their preferences.
- The what_id supports more thanone module in a single query.
- You can retrieve the consent-related information using the ConsentsLookupfields in your query.
- From V7, when you specify a lookup field in the SELECT column of a query, the response includes the associated record’s display field value under the "name" key within the "lookup"JSON along with the "id" key.
- Note:
If you query the Users lookup field in the SELECT column, the corresponding record’s last name (display field) will be displayed in the "name" key of the corresponding "lookup" JSON response. - Display field value will not be available for Consent Lookup and Multi-Module Lookup(MML) fields.
- Note:
- Until V6, the only supported comparators for Profile Image field (with "api_name": "Record_Image" and "data_type": "profileimage") were "is not null" and "is null".
The Profile Image field supports the following comparators: "is null", "is not null", "=", "!=", "in", "not in", "like", "not like". - The Rollup Summary field now supports additional comparators: "=", "!=", ">=", ">", "<=", "<", "between", "not between", "in", "not in", "is null" and "is not null". Until V6, only "is null" and "is not null" were supported.
- Note: From V7, the response for the Date and Datetime return types of the Rollup Summary field will be provided in their respective formats.
- The JOIN support limit has been increased from two to five. It means, a single query can have a maximum of five JOINs.
- From V7, If there are two lookup fields pointing to the same module (Example: Owner.role and Created_By.profile pointing the Users module) in the SELECT Column JOIN, then the both the lookup fields will be treated as a single JOIN.