Changelogs

We update Zoho CRM APIs frequently with new features to suit your evolving business needs. These changelogs document all the notable changes made to Zoho CRM APIs in version 3.

API Domain

For V2.1 and above versions, you must use the dedicated domain name to make API calls. The default domain is: https://www.zohoapis.com/ (US)
This is helpful in serving CORS requests. The other supported domains are:

Europe - https://www.zohoapis.eu/
China - https://www.zohoapis.com.cn/
India - https://www.zohoapis.in/
Australia - https://www.zohoapis.com.au/
Japan - https://www.zohoapis.jp/

For more information, refer to Multi DC Support. If you fire API calls with a domain other than https://www.zohoapis.{dc}, the system will throw INVALID_HOST error with HTTP status 400.

Version V3

The Zoho CRM APIs with updates that apply to the V3 version are listed below.

Note

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.

Activities
- From this version you cannot make API calls to the Activities module. You must make module-specific calls such as Meetings, Calls, and Tasks.
Modules API
- Five modules from Zia Recommendation are introduced—Bunches__s, Cross_Sellings__s, Rebuys__s, First_Buys__s and Next_Buys__s.
- The modules Email_Analytics, Services__s, Appointments__s, and Appointments_Rescheduled_History__s are introduced.
- The property $client_portal_permission is introduced that indicates whether the records and the notes in that module can be shared with other users of the portal.
Get Profiles API
- The following keys are introduced:
  - type: Represents if the profile is a normal_profile, lite_profile or portal_profile.
  - profile_permissions: This key gives the details of the view, create, edit, and delete permissions given to the profile for different modules. Note that this array is rendered in the response only when you fetch a specific profile.
- The modules Email_Analytics, Services__s, Appointments__s, and Appointments_Rescheduled_History__s are introduced.
- The property $client_portal_permission is introduced that indicates whether the records and the notes in that module can be shared with other users of the portal.
Users API
- The territories key is removed from the Get Users response.
- New error case is added when a user rejects the invitation sent to be added to the org.
- Four new APIs are included in this version to get, assign and update the territories of a user, validate the open records before transferring them, and to delink and transfer the open records in the territory to a new user.
Organization API
- The deletable_org_account key is introduced which represents whether the account related to that org is deletable or not.
Fields and Layouts Metadata API
- Leads: New fields Converted_Contact, Converted_Deal, and Converted_Account are introduced. Note that these keys are rendered in the response when you fetch a converted lead by its ID or using the parameter "converted=true" for the Leads module in the Get Records API. For the non-converted leads, the value for the above keys will be "null".
- The boolean property searchable is introduced, which represents whether the field in that module is searchable.
- The boolean property virtual_field is introduced which represents if the field is virtual. Virtual fields are those that are used for reference purposes in subforms, multi-select lookups, multi-select user lookups, ISONLINE, FULL_NAME etc. These fields contain meta properties but do not have actual values.
- The property sharing_properties is introduced, which represents if the user has access to the records that the field looks up to.
- The boolean property enable_colour_code is introduced that represents whether color-coding is enabled for a field.
- The property colour_code is introduced in pick_list_values array. This represents the color code used for that picklist's value.
- The values of the status key are changed. It represents the status of the layout to the user. The values are "active", "inactive", "downgrade", and "hidden".
- A new data type, multi-module lookup, has been introduced. It allows you to link records from multiple modules using a single lookup field.
- The parameter include=allowed_permissions_to_update is introduced to get the read/write customization permission for a field. For example: "read_only":true denotes that the field can be used as a read-only field.
- Deals: The data type of the key forecast_category in Stage Probability Mapping of the Deals module is changed from string to JSON object.
- Users: New fields Number_Separator and Decimal_Separator are introduced.
- Meetings: The data type of the key Remind_At is changed to multireminder.
- Appointments ("api_name": "Appointments__s") :
  - The Appointment_For multi-module lookup field has been added to the Appointments module.
- Layouts Metadata: Besides the above changes, the following are the additional changes in this API.
  - The "sections" array has a new key "id" that represents the unique ID of that section.
  - New keys source and generated_type are added. "source" represents whether the layout was created from a campaign integration, platform or marketplace plugin, or CRM.
    "generated_type" represents whether the layout is custom or system-generated.
Custom View Metadata API
- A new key locked is included in the response. This represents if the current custom view is locked for editing. When a custom view is locked, only Admins and creators can modify it. We have also added the related error cases.
Related Lists Metadata API
- The parameter layout_id is supported from this version. When you specify a layout's ID, the metadata of the related lists in that layout will be fetched.
- The keys customize_sort, customize_fields, customize_display_label are introduced in the response.
- The related list Appointments_Rescheduled_History__s is introduced.
Insert and Update Records APIs
- Meetings module: The format of Remind_At for recurring meetings is changed. This array contains the "unit" and "period" keys in each JSON object.
- Tasks module: The "FREQ" key under "Remind_At" JSON object is not supported. From this version, you cannot set up multiple reminders for a task. This "Remind_At" JSON object will be in the format "ALARM":"ACTION=EMAIL_or_POPUP;TRIGGER=DATE-TIME:<DateTime_in_ISO8601>".
- wizard_connection_path: This JSON array accepts the IDs of the wizard connection paths when you create a record in a wizard.
- In the response, the key approval_state is added that represents the approval state of the record if it enters the approval process.
- Relevant error codes for the Appointments module are added.
- Relevant error code added for multiple duplicate records.
Get Records API
- fields is a mandatory parameter when you want to fetch all records from a module. This parameter takes up to 50 field API names you want in the response.
- If your requirement is to fetch under 2000 records, use the "page" and "per_page" parameters (page=1 to 10, per_page=200).
- If you want to paginate for more than 2000 records, use the "page_token" parameter you receive in the first response. Using this next page token in the consecutive requests, you can navigate and fetch up to 100,000 records.
  Note that for this case, you can use page_token from page=2 itself, instead of page and per_page parameters. If there are more records, the API responses, will have "next_page_token" and "previous_page_token" for easy pagination.
- Note that in both the above scenarios, the maximum records per request will be only 200.
- You cannot use the cvid and sort_by parameters together. When you use sort_by, you can only sort the records based on the Modified_Time, Created_Time, and id fields.
- wizard_connection_path: This JSON array gives the IDs of the connections that represent the sequence in which the user filled up valid information on a screen. This key is available in the response only when you fetch a specific record.
- A new parameter on_demand_properties = "$client_portal_permission" returns the "$client_portal_permission" JSON object in the response. The boolean values to the keys "record" and "notes" represent whether the record is visible to users of the portal and if notes can be shared to others, respectively. You can use this parameter only while fetching a specific record.
- In the Tasks module, the parameter uid is introduced to fetch the recurring tasks by their recurring IDs($u_id).
- From V3, the "approved" parameter will no longer be available in the GET - Records API. Instead, use the "approved_state" parameter, which supports multiple values, to list the various approval stages of records if they enter the approval process.
Convert Lead API
- A new API Get Lead Conversion Options is introduced. This API fetches the records in Deals, Contacts, and Accounts modules that match the data in the lead record. You can then convert the lead and associate it to the relevant records in these modules to avoid duplicate data errors.
- When you convert a lead, even the multi-select lookup and multi-select user lookup fields are converted.
- The key move_attachments_to is introduced. This JSON object represents the API name of the module you want to move the attachments of the lead to. You can specify the API name of either Deals, Contacts, or Accounts.
Search Records API
- You can search for and fetch a maximum of 2000 records using this API. Exceeding this limit will result in the "LIMIT_REACHED" error.
- fields is a new optional parameter in this API that you can use to fetch the values of specific fields. This parameter takes up to 50 field API names.
- New error cases are added.
Update Subform API
- The update functioning has been modified. Henceforth, the update operation on a subform record will append the provided data with the existing data. For instance, consider a subform "Proficiency", which has a record with ID "50402XXXX123". When you update the parent record with the subform data but without sending the record ID of the existing subform record, the subform will now have two rows with IDs "50402XXXX123" and "50402XXXX456"(newly appended record ID).
- Also, providing the key "_delete" as "null" will delete the subform record.
- New sample input cases are added
Tags API
- In Get tags API, a new key colour_code is introduced. This key represents the hex value of the color you have chosen for that tag.
- You can also color-code your tags while creating or updating them. Specify one from the list of supported colors for tags in the request body.
Records Share API
- A new key type is included in Get Shared Records Details, Update Share Permissions, and Revoke Permissions APIs. This key represents whether the record is shared publicly to all users in the org or privately to a specific user.
- The user object in the response of Get Shared Records API is now changed to shared_with. This key contains the details of the user that the record is shared with.
Delete Variables API
- You cannot delete a variable if it is in use in other places like webhooks, custom links, templates, etc. The relevant error cases are added.
Get Wizards API
- The response contains the following new keys:
  - conditional_rules: For each screen, there will be an array of conditional rules. Each rule will have criteria and set of actions.
  - message: You can now display acknowledgment messages in wizards. The response contains the title and content of the acknowledgment.
  - buttons: This key contains the details of the buttons used in various segments of a screen.
Query API
- You can use pagination (through OFFSET and LIMIT) and fetch up to 10,000 records using this API. Refer to the Pagination section to know more details.
- The select query now supports "alias". You can fetch the record's details and receive the relevant data in the field specified in the alias.
- You can now fetch the owner's profile details such as ID, name, created_by, modified_by, description, created_time, modified_time, and the details of the role such as ID, name, reporting_to, share_data_with_peers, description from a module.
- New format introduced for module API name in the select query. All module names must have the prefix ! to differentiate between a module's and a field's API names.