Zscaler Applications (CM360 Connector) – HUBDB Table and API Call Docs

For Detailed Application Docs:- https://cm360.securedynamics.net/kb/cm360-connector-app

1. HUBDB Table Assignment

This section describes how the CM360 Connector App data is stored in HubSpot HUBDB tables.

1.1 Business Table

HubDB Table Name: cm360_connector_organization

Purpose:
Stores all business-level configuration and Zscaler connection details.

Key Columns:

name – Business Name (Required)
description – Business Description (Required)
url – Zscaler portal URL
username – Zscaler username
password – Zscaler password
api_key – Zscaler API key
custom_tags – JSON data for custom tags that have been fetched
created_at – Record creation timestamp
updated_at – Last updated timestamp

The checkmark (✅) and cross (❌) icons on the Business page are driven by the presence/validity of: url, username, password, and api_key.

1.2 Cloud Applications Tables

HubDB Table Names:

cm360_connector_cloudapp_a_d
cm360_connector_cloudapp_e_h
cm360_connector_cloudapp_i_l
cm360_connector_cloudapp_m_p
cm360_connector_cloudapp_q_t
cm360_connector_cloudapp_u_x
cm360_connector_cloudapp_y_z

Purpose:
Store information about cloud applications retrieved from Zscaler and their sanction status.
Applications are split alphabetically across different tables based on their starting letter.

HubDB Limitation:
HubSpot HUBDB supports a maximum of 10,000 rows per table.
Since the list of Zscaler cloud applications can grow beyond this limit, we split the cloud applications into multiple tables by alphabetical range (A–D, E–H, I–L, etc.).
This design ensures:

We stay within the 10,000-row limit per table, and
The UI can still query and filter apps efficiently by range.

Key Columns (common across all these tables):

name – Cloud application name
app_id – Unique ID of the app from Zscaler
status – Possible values: sanctioned, unsanctioned
created_at – Record creation timestamp
updated_at – Last updated timestamp

The search and alphabetical filtering in the UI use the name column (for text search) together with the table naming convention (…_a_d, …_e_h, etc.) to jump to the correct range.

1.3 Logs Table

HubDB Table Name: cm360_connector_activity_logs

Purpose:
Stores execution logs for sanction/unsanction operations.

Key Columns:

business_name – Business for which the action was attempted
apps – List of apps involved in that operation
status – success, invalid_credentials, failed
message – Detailed success or error description when applicable
payload – JSON of the request data
organization_id – Reference ID of the business (cm360_connector_organization)
created_at – Log timestamp

The Logs page in the UI reads from this table to display:
Business Name, Status, and the list of Applications per operation.

2. API CALL Documentation & Counts

This section lists the main internal APIs used by the CM360 Connector App.
You can fill in the API Count columns from logs / analytics.

2.1 Internal API Inventory & Counts

#	API Name	Method	Path	Description	Used In
1.	Get All Businesses	GET	/organizations	Retrieves all business records	Business page Load/refresh
2.	Create Business	POST	/organizations	Create a new business with Zscaler settings	Create Business Form
3.	Update Business	PUT	/organizations/{id}	Updates Business Name, Description, and Zscaler Details	Update Business Form
4.	Delete Business	DELETE	/organizations/{id}	Delete an existing business	Delete Business (🗑️)
5.	Fetch Custom Tags	GET	/zia-apps/customTags?organization_id={id}	Logs into Zscaler and fetches all custom tags for business	‘Fetch Custom Tags’ button
6.	Get Cloud Applications	GET	/applications?tableName={a_d}&pageno={pageno}	Lists cloud apps (supports range/search filters).	Cloud Applications page
7.	Apply Sanction/Unsanction (Bulk)	PUT	/zia/multipleApps	Applies sanction/unsanction actions in Zscaler, assigns tags, logs result.	Apply step (Business selection)
8.	Get Logs	GET	/logs	Returns log entries (Business Name, Status, Applications list).	Logs page list view

2.2 Authentication (Auth0 – Hosted Pages)

The following user flows are handled by Auth0 Universal Login, not by CM360’s own APIs:

Login
Forgot Password
Reset Password

These screens and their logic are provided by Auth0.
The CM360 Connector App:

Redirects the user to Auth0’s hosted login / reset pages.
Receives the authentication result (tokens) from Auth0.
Does not expose its own /auth/login, /auth/forgot-password, or /auth/reset-password API endpoints.

Therefore, these flows are not listed in the internal API table below, and API counts for them (if needed) should be obtained from Auth0 logs/analytics, not from CM360 backend logs.

2.2 External Zscaler API Calls (Reference)

Note: These endpoints are called by the CM360 Connector backend against the ZIA tenant

(e.g. `https://<cloud>.zscaler.net/api/v1` + endpoint path).

#	API Name	Method	Zscaler Endpoint	Purpose
1.	ZIA API Authentication	POST	/authenticatedSession	Creates an authenticated API session using admin username, password, API key, and timestamp.
2.	Get Cloud Applications	GET	/cloudApplications/lite?pageNumber=0&limit=100	Retrieves the list of Zscaler cloud applications used by the connector.
3.	Bulk Update Cloud Apps	PUT	/cloudApplications/bulkUpdate	Updates sanction/unsanction status and related settings for multiple cloud applications at once.
4.	Get Custom Tags	GET	/customTags	Fetches all custom tags configured in ZIA for use when tagging cloud applications.

Bulk Update API Call Behavior (Sanction vs Unsanction Selection):

If only Sanction apps are selected → the connector performs 1 Zscaler `bulkUpdate` API call.
If only Unsanction apps are selected → the connector also performs 1 Zscaler `bulkUpdate` API call.
If the selection contains both Sanction and Unsanction apps in the same operation → the connector splits the request by action type and performs 2 Zscaler `bulkUpdate` API calls.
(one for the Sanction group and one for the Unsanction group).