The Datazoom CLI Utility, commonly referred to as DZCLI, is a command-line interface for interacting with the Datazoom platform without relying exclusively on the web console. It is intended for technical users who want a precise, scriptable, and automation-friendly way to inspect and manage Datazoom configuration objects such as collectors, connectors, and data pipes. In practice, DZCLI brings Datazoom administration closer to an infrastructure-as-code model: configurations can be queried, reviewed, updated, and incorporated into repeatable operational workflows.

At a high level, DZCLI is the terminal-based administrative interface for Datazoom platform configuration. Its value is speed, repeatability, and suitability for scripting, CI/CD, testing, and bulk operational work.

Setup and quick start

Before using DZCLI, the local environment needs Git, Python 3, and the matching pip3 installer. To download the tool from GitLab, create a GitLab Personal Access Token with a simple token name, such as dzcli-token, and the read_repository scope.

git clone https://<your-gitlab-username>:<your-access-token>@gitlab.com/datazoom/platform/python-dzcli.git
cd python-dzcli
pip3 install -r requirements.txt
pip3 install .

After installation, store Datazoom credentials, authenticate, and verify access:

dzcli cred <username> <password>
dzcli login
dzcli user details self

A future authentication improvement under consideration is generating a token from the Datazoom console and using that token for CLI authentication.

What the utility is for

Datazoom’s platform is built around a few core concepts: Collectors gather data, Data Pipes decide what to keep and how to route it, and Connectors deliver processed data to downstream systems. DZCLI is designed to let operators work directly with those platform objects from a shell or automation environment.

Instead of navigating page by page through the console UI, a user can run structured commands to retrieve configuration details, list supported object types, update selected properties, and manage relationships between objects. This is especially useful when the same operation must be repeated across environments, tested against known accounts, or embedded in a larger deployment process.

Core operating model

DZCLI follows a resource-oriented command structure. Commands are grouped by major Datazoom entities such as collector, connector, datapipe, and user. Each group exposes operations appropriate to that resource, such as listing, reading details, or updating configuration.

The tool has been designed around straightforward terminal syntax such as invoking a resource followed by an action, for example dzcli.py collector ... or dzcli.py datapipe .... This makes the utility predictable for engineers who are used to other administrative CLIs.

The installed command is dzcli in the setup flow. Some examples and packaged-runner workflows may also invoke the utility as ./dzcli.pyz; the resource/action structure is the same.

Primary objects managed by DZCLI

Object	Role in Datazoom	CLI relevance
Collector	Defines how data is collected from an application, player, SDK, or source	Can be listed, inspected, and updated for selected properties
Connector	Defines where Datazoom sends processed data	Can be listed, inspected, and updated for selected properties
Data Pipe	Combines collectors, selected data points, and connectors into a delivery flow	Can be listed, inspected, updated, and modified to add or remove linked configurations
User / company scope	Determines account access context	Supports company selection workflows for admins with access to multiple companies

Supported capabilities

DZCLI has been designed to support real administrative work against live Datazoom accounts.

Read and list operations

DZCLI supports read-oriented access to key Datazoom resources. This includes listing collectors, connectors, and data pipes, as well as retrieving details needed for review, troubleshooting, or change planning.

Collectors: list existing configurations and inspect details
Connectors: list existing downstream destination configurations
Data Pipes: list pipes and inspect pipe details, including associated collector configuration information
Supported types: command patterns indicate support for querying supported collector or connector types using filters such as type or deprecation state

Quick command reference

Area	Command or options	Purpose
Base collectors	`dzcli collector supported-base` `--type [PLAYER\|CDN]` `--supportSampling [true\|false]` `--appSessionTimeoutEnabled [true\|false]` `--category [criteria]` `--restricted [true\|false]` `--show-datapoints [all\|required\|deprecated]`	List supported base collectors, filter them, and optionally include data point metadata.
Collector extensions	`dzcli collector supported-plugins` `--collectorName [string]` `--supportCMCD [true\|false]` `--restricted [true\|false]` `--category [criteria]` `--show-datapoints [all\|required\|deprecated]`	List media-player or CDN-vendor extensions for collectors and inspect their data points.
Extension-of-extension / ad frameworks	`dzcli collector supported-frameworks <media-player-id>`	List ad-framework-style extensions associated with a media-player collector. Additional filtering and data point display for this area were identified as follow-up work.
Supported connectors	`dzcli connector supported` `--connectorName [string]` `--supportEncryption [true\|false]` `--supportAggregation [true\|false]` `--deprecated [true\|false]` `--restricted [true\|false]` `--category [criteria]`	List and filter supported connector types.
Collector configurations	`dzcli collector list` `--collectorName [string]` `--playerName [string]` `--disabled [true\|false]` `--projectName [string]` `dzcli collector set ["<data>"\|"@<filename>"]`	List, filter, and update collector configuration objects.
Connector configurations	`dzcli connector list` `--connectorName [string]` `--disabled [true\|false]` `--projectName [string]` `--transformEnabled [true\|false]` `dzcli connector set ["<data>"\|"@<filename>"]`	List, filter, and update connector configuration objects.
Data pipes	`dzcli datapipe list` `dzcli datapipe list --show-config-id` `--title [criteria]` `--disabled [true\|false]` `dzcli datapipe details [<datapipe-id>]` `dzcli datapipe set ["<data>"\|"@<filename>"]`	List data pipes, show linked collector and connector configuration IDs, filter by title or disabled state, retrieve details, and apply updates.
Users and companies	`dzcli user details [<user-id>\|self]` `dzcli user companies`	Inspect the current user or another user by ID, and list companies available to the authenticated user.

Basic update operations

DZCLI has explicit support for basic updates to platform objects using structured payload input. For collectors, connectors, and data pipes, documented update shapes include fields such as:

id — required identifier of the object to update
name — updated display name
disabled — enable/disable state

These updates are described as being accepted inline or via file input, which is significant because it allows a user to store intended changes in version-controlled JSON or YAML files, review them, and apply them consistently.

Structured input formats

DZCLI is designed to accept structured configuration data as JSON input with file-based invocation using an @filename pattern. The @my_datapipe_config.json or @mydatapoints notation means “read the request body from this file,” similar to curl syntax for sending data to a POST call. This makes the CLI suitable for:

Checked-in configuration artifacts
Automated deployment scripts
Change review workflows
Repeatable edits across environments

Data point selection inside data pipes

One of the more important administrative capabilities associated with DZCLI is the ability to update which data points are selected within a data pipe’s collector configuration. The structure supports granular selection changes across:

eventList
fluxDataList
metaDataList

Each item is represented by a dictionary-version data point mapping identifier and a boolean selected value. This means DZCLI is not limited to coarse object management; it is also intended to support detailed control over what a data pipe collects and forwards.

This is one of the CLI’s most operationally valuable functions because it allows teams to manage collection scope precisely without manually editing selections in the UI.

Recommended data point update workflow

The detailed data point workflow starts by listing data pipes so the operator can copy the target data pipe ID:

dzcli datapipe list

Then retrieve the current data point settings in edit-ready form. The --show-datapoints "set" mode is important when the goal is to edit and reapply data point selections:

dzcli datapipe details <datapipe-id> --show-datapoints "set" > mydatapoints

In the exported file, identifier fields such as id, configId, and dataPointId are critical and should not be modified. Human-readable fields such as name and mediaType are informational; the operational change is the boolean selected value for each data point.

{
  "id": "1685f7c5-4ed8-4882-9063-7a23227c6ee4",
  "name": "Xminds_datapipe",
  "collectorConfigs": [
    {
      "configId": "fa1fb61a-0a12-491d-a62e-4a2fa7531acb",
      "configName": "123new",
      "general": {
        "eventList": [
          {
            "dataPointId": "daf4c2b4-1bda-4241-b3cb-4fddf785839c",
            "name": "datazoom_loaded",
            "selected": true,
            "mediaType": "not_appl"
          }
        ],
        "fluxDataList": [
          {
            "dataPointId": "b3e5521a-8576-4554-9c35-f2e9f6ae3e16",
            "name": "engagement_duration_ms",
            "selected": true
          }
        ],
        "metaDataList": [
          {
            "dataPointId": "b7800c6d-0fe1-47a9-b4ba-0956c4d30715",
            "name": "ad_blocker",
            "selected": true
          }
        ]
      }
    }
  ]
}

After editing selections, apply the update:

dzcli datapipe set @mydatapoints

A successful update returns a response shaped like {"data": null, "success": true, "message": "Successfully updated data pipe.", "errors": null, "code": null}.

DZCLI attempts to dump collector and data point configuration in a consistent order. This makes it practical to compare files such as old_datapoint_dump and new_datapoint_dump, commit snapshots to Git, and detect later selection changes as well as data points that have been authored or de-authored since the previous dump.

Managing relationships inside a data pipe

DZCLI also supports updating data pipe composition by adding or removing linked collector and connector configurations. Example options include:

--add-collector <collector-config-id>
--remove-collector <collector-config-id>
--add-connector <connector-config-id>
--remove-connector <connector-config-id>

This turns the CLI into more than a read-only reporting tool: it becomes a practical mechanism for changing how data flows through the platform.

dzcli datapipe update \
  --add-connector <connector-config-id> \
  --remove-connector <connector-config-id> \
  --add-collector <collector-config-id> \
  --remove-collector <collector-config-id>

Admin company selection

For administrative users who can access more than one company, DZCLI is intended to support account-scope selection:

a command to list accessible companies, such as user companies
a --company <id> option to direct a command at the intended company context

This is important for avoiding ambiguity and for safely operating in multi-tenant administrative scenarios.

What DZCLI is not

DZCLI should not be thought of as a separate data collection SDK or a runtime collector library. It does not collect events from applications. Instead, it is an administrative tool for managing the Datazoom platform objects that control collection, routing, and delivery.

It is also distinct from the customer-facing SDKs used in JavaScript, mobile, CTV, or server-side integrations. Those SDKs emit data. DZCLI manages the platform configuration around that emitted data.

Typical usage scenarios

Environment synchronization: compare or apply known collector, connector, or data pipe settings across accounts
Safe bulk administration: update names, enable/disable states, or linked configurations across multiple objects
CI/CD workflows: apply configuration changes from stored JSON or YAML files during deployment processes
Testing and QA: prepare a test company account in a known state, then modify and destroy objects as part of automated tests
Data governance: programmatically control which events, metadata, and flux data are selected in a data pipe