Kaizen #116 - Client Types in Zoho API Console

Kaizen #116 - Client Types in Zoho API Console

Hello everyone!
Welcome back to another post in the Kaizen series!

This week, we will discuss different client types available in Zoho API Console, and when to use each.

When you register an app in Zoho API Console, you typically choose a client type based on how your application interacts with Zoho services.
Let us discuss the available client types and how authorization is handled for each.

Available client types

  1. Server-based
  2. Client-based
  3. Self client
  4. Non-browser-based
  5. Mobile-based

1. Server-based

If you have a web-based application that runs on a dedicated HTTP server and interacts with Zoho services by calling Zoho APIs via that server, you must register your app with this client type.
This client type is for applications that redirect the users to another URL on a web browser to authorize themselves, where they give consent to your application to use their data.
In other words, you must use this client type when you have a front-end web UI and require user intervention before your app can access user data via the dedicated server.

Consider that you are developing a web-based custom application. Users authorize that app via browser to allow their Zoho CRM data to be accessed and used by that application.
During the registration process in Zoho API Console, you would choose the "Web-based" client type.
OAuth 2.0 would be used for user authentication, allowing your app to securely access and interact with Zoho CRM data on behalf of the users.

Here is a gist of what happens:
  1. Users visit your website where you have the Login with Zoho button.
  2. When a user clicks it, that user will be redirected to accounts.zoho.com with the details of your app such as client ID, scope, redirect uri, access type as the URL parameters.
  3. Your app must make an API call to Zoho Accounts with the client ID, scope, redirect uri, and access type. Users are shown the data that your application wants to use.
  4. When users give their consent, Zoho redirects them back to your app.This will be the "Redirect URL" you give while registering your app.
  5. The redirect URL will have the authorization code(grant token) as one of the parameters, along with the location(user's domain).
  6. Your app must then make API calls from your web server to Zoho Accounts to generate access and refresh tokens with the generated grant token.
  7. You must store these tokens in your DB to access that user's data in Zoho CRM. While making API calls, you must send this access token in the header.
  8. Your app must also have the logic to regenerate access tokens from refresh tokens when the access token expires.
Note that your app must take care of storing user's details like email, organization ID, and tokens.

The following image shows the protocol flow.


You can use any of our server-side SDKs to simplify this process.
When you use our SDK, all you have to do is, generate the grant token and initialize the SDK with the client details and this token. The SDK takes care of access token generation, refreshing it, and token storage.


For more details, you can refer to the Accounts guide and CRM help doc.

2. Client-based applications

This client type is for applications that do not have a server and run exclusively on a web browser.
This is also called the Implicit flow as your app makes API calls to Zoho only when users are using your app.
This type of application loads data dynamically on the webpage, and accesses Zoho CRM data by making API calls via Javascript.

Consider the same example where there is a Login with Zoho button on your webpage.
Here is a gist of what happens when a user clicks it.
  1. Your app redirects the user to Zoho Accounts.
  2. Your app makes the authorization request with the client ID, redirect uri, scope, and response type as token.
  3. The user is shown the data that your webpage would use.
  4. When the user gives consent, Zoho Accounts sends the access token to the redirect uri as a parameter, along with the expiry time and the location of user's data in Zoho's accounts server.
  5. You can include the "email" in your scope parameter in the access token request to get user's information. The response will have a parameter called id_token that will be in the header.payload.signature format. You need to decrypt the payload section of the parameter using the base-64 decryption algorithm to get user information.
  6. Your app must then make API calls to Zoho with this access token to fetch data.
  7. When the access token expires, your app must take care of regeneration and storage.


As the API calls are made from your domain to a different domain(zohoapis.com), for security reasons, the browser will throw the CORS error. So, your domain will be registered while registering your app, and Zoho will know to allow the API calls made from that domain.

As the tokens are available on the browser itself, we recommend handling them with care.
When you use our client-side JS SDK, it automatically generates a new access token upon expiry.

3. Self Client Applications

When your application does not have a redirect URL or a UI, but performs only a backend job, and does not need user intervention, then you must choose this client type.

A self client is often used when the application and Zoho services are operated by the same entity, and you want to enable secure communication between them. For example, you have an internal reporting tool and integrate it with Zoho Analytics. In this case, both the tool and Zoho Analytics are operated by the same entity.
Similarly, consider that you have a legacy product management system and want to perform data sync between Zoho CRM and the system, then you must use the self client.

Here is a gist of what happens.
  1. You register your app as self client in Zoho API Console.
  2. You will get the client details such as ID and secret.
  3. You provide the scopes required for your app to access CRM data.
  4. You will receive the grant token.
  5. Your app must then make API calls to Zoho Accounts to generate access and refresh tokens.
  6. Your app can then use this access token to make API calls to Zoho CRM and use data.
You can refer to our older Kaizen post on this topic for more details.
Note that self client apps can also use any of our server-side SDKs. As already said, the SDK takes care of access and refresh token generation, refreshing the access token, and token storage.

4. Non-browser applications

This client type is for devices that do not have a user agent such a web browser. A TV, for instance.
Let us consider an example involving a smart TV application that integrates with Zoho ShowTime. In this scenario, the smart TV application acts as a non-browser client.
Here is how authentication is handled:
  1. You must register your smart TV app in Zoho API Console with the type "Non-browser application".
  2. Users install a dedicated Zoho ShowTime application on their smart TVs.
  3. When users launch the Zoho ShowTime application on their smart TV, they are prompted to authenticate with their Zoho ShowTime account.
  4. When they successfully authenticate, Zoho Accounts sends the grant token to your app, along with the user-code, device-code and verification URL,The user must go to this verification URL on a browser and enter the user-code to grant permission to the app.
  5. Meanwhile, your app must poll the accounts server using the grant token to check if the token has been received.
  6. When the user enters the user code, Zoho Accounts sends the access token to your app.
  7. Your app can then use the access token to make API calls to Zoho. Your app must take care of token storage and renewals.

Here is the protocol flow. For more details, refer to this doc.


5. Mobile-based applications

You must use this client type when you have developed an app exclusively for mobile devices. The protocol flow is similar to server-based application where a browser session is required for the users to authenticate.



Similar to server-side apps, mobile apps also need to handle redirection, token generation and storage.
If you use any of our Mobile SDKs, the SDK itself handles token generation and storage.

We hope you found this post useful. Let us know your thoughts in the Comment section or write to us at support@zohocrm.com.


Cheers!