Authenticating to Zoho CRM
Zoho CRM uses the OAuth authentication standard. To authenticate using OAuth, you will need to create an app to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
The Zoho CRM provider defaults UseServerSideFiltering to True for higher performance, though it may return incorrect results.
Using OAuth Authentication
OAuth requires the authenticating user to interact with Zoho CRM using the browser. The provider facilitates this in various ways as described below.
Custom Credentials
You will need to register an app to obtain the OAuthClientId and OAuthClientSecret.
Web Applications
You need to create an OAuth app to use in the web flow.
Desktop Applications
You need to create an OAuth app.
Headless Machines
In the headless OAuth flow, users need to authenticate via a browser on another machine. You will need to create a custom OAuth app.
Creating a Custom OAuth App
Zoho CRM uses the OAuth authentication standard, which requires the authenticating user to interact with Zoho CRM via the browser. The provider facilitates the OAuth exchange in various ways as described below.
Registering an OAuth Application
Before you get started with authorization and make any calls to the Zoho CRM API, you need to register your application with Zoho CRM. You can follow the procedure below to obtain the OAuthClientId, OAuthClientSecret, and CallbackURL connection properties.
- Go to accounts.zoho.com/developerconsole
- Click Add Client Id.
- Enter the client name, domain, and redirect URL.
-
If you are connecting from a desktop application, set the callback URL to http://localhost:33333, or another port number of your choice.
If you are connecting from a Web application, set the callback URL you want to be used as a trusted redirect URL, where the user will return with the token that verifies that they have granted your app access.
- Click Create.
Authenticate to Zoho CRM from a Desktop Application
After setting the following connection properties, you are ready to connect:
- Domain: Set this to `eu` if your account uses the crm.zoho.eu domain instead of the crm.zoho.com one. If your account uses .com TLD, do not set this connection property at all.
- InitiateOAuth: Set this to GETANDREFRESH. You can use InitiateOAuth to avoid repeating the OAuth exchange and manually setting the OAuthAccessToken connection property.
- OAuthClientId: Set this to the client Id you defined for your OAuth app.
- OAuthClientSecret: Set this to the client secret you defined for your OAuth app.
- CallbackURL: Set this to the callback URL you defined for your OAuth app.
- Extracts the access token from the callback URL and authenticates requests.
- Obtains a new access token when the old one expires.
- Saves OAuth values in OAuthSettingsLocation to be persisted across connections.
Authenticate to Zoho CRM from a Web Application
Follow the steps below to get and manage the OAuth token values in the Web flow.
Get an Access Token
Set the following connection properties to obtain the OAuthAccessToken:
- OAuthClientId: Set this to the Client Id in your app settings.
- OAuthClientSecret: Set this to the Client Secret in your app settings.
Zoho CRM Server Side Filtering
The provider supports converting equals (=) and startswith (LIKE 'mystring%') SQL filters to the appropriate Zoho CRM API requests. This is called UseServerSideFiltering which is set to True by default, and provides higher performance by selecting fewer data.
However, Zoho CRM can return incorrect sets of results with filters for records that have been recently modified. While records are instantaneously modified and always reflect the current values, records will match a filter based on the record's previous state for a brief period after being modified (usually 3-4 minutes). For example, a record with an attribute like Industry='ASP' may be returned for a filter WHERE Industry='ERP' if the record recently had the value 'ASP'.
In cases where it is necessary to filter results accurately by their current states, UseServerSideFiltering may be set to False to retrieve all records and filter the results client-side. This may be a significantly more expensive operation.
Customizing the SSL Configuration
By default, the provider attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store. To specify another certificate, see the SSLServerCert property for the available formats to do so.
Connecting Through a Firewall or Proxy
HTTP Proxies
To connect through the Windows system proxy, you do not need to set any additional connection properties. To connect to other proxies, set ProxyAutoDetect to false.
In addition, to authenticate to an HTTP proxy, set ProxyAuthScheme, ProxyUser, and ProxyPassword, in addition to ProxyServer and ProxyPort.
Other Proxies
Set the following properties:
- To use a proxy-based firewall, set FirewallType, FirewallServer, and FirewallPort.
- To tunnel the connection, set FirewallType to TUNNEL.
- To authenticate, specify FirewallUser and FirewallPassword.
- To authenticate to a SOCKS proxy, additionally set FirewallType to SOCKS5.
Troubleshooting the Connection
To show provider activity from query execution to network traffic, use Logfile and Verbosity. The examples of common connection errors below show how to use these properties to get more context. Contact the support team for help tracing the source of an error or circumventing a performance issue.
- Authentication errors: Typically, recording a Logfile at Verbosity 4 is necessary to get full details on an authentication error.
- Queries time out: A server that takes too long to respond will exceed the provider's client-side timeout. Often, setting the Timeout property to a higher value will avoid a connection error. Another option is to disable the timeout by setting the property to 0. Setting Verbosity to 2 will show where the time is being spent.
- The certificate presented by the server cannot be validated: This error indicates that the provider cannot validate the server's certificate through the chain of trust. If you are using a self-signed certificate, there is only one certificate in the chain.
To resolve this error, you must verify yourself that the certificate can be trusted and specify to the provider that you trust the certificate. One way you can specify that you trust a certificate is to add the certificate to the trusted system store; another is to set SSLServerCert.