Zscaler coverage

Beyond ZIA, ZPA and ZDX: Zscaler operations through OneAPI

ZIA, ZPA and ZDX are important areas of work, but they are not the entire Zscaler world. CentaurNexus uses the official OneAPI as a shared contract boundary for supported workflows across further domains.

August 4, 2026 · CentaurNexus · Reading time approx. 6 minutes

Multiple Zscaler domains converging through a shared integration layer
CentaurNexus: Beyond ZIA, ZPA and ZDX: Zscaler operations through OneAPI

OneAPI is the shared access layer

Zscaler describes OneAPI as a central access point for supported APIs. API clients receive scopes and roles. CentaurNexus builds on this foundation and adds a multi-tenant operational, governance and integration layer. Zscaler remains the core provider and source of target-system data.

View domains rather than isolated portals

Depending on the tenant and supported workflow, operations can include contexts beyond ZIA, ZPA and ZDX, including ZCC, ZTW, ZIdentity, EASM, Z-Insights, ZMS and other domains available through documented interfaces. CentaurNexus connects these domains in a shared role-based operating context.

OneAPI itself is not tenant-dependent. Licensed domains, configured API scopes, data sources and therefore concrete coverage depend on the tenant.

Coverage must remain visible

Each supported read shows source, status, data age and coverage. Available domains and workflows remain visible for the connected tenant.

One work context for multiple roles

End users, help desk, administrators, security, MSPs, management and platform operations need different views. CentaurNexus connects them through role-based workflows. Broad vendor-admin rights do not become the default access level for every operator.

API client, resource and scope belong together

OneAPI uses API clients and assigned resources. A client receives only the scopes configured for the connected Zscaler services. A technically available interface is therefore not automatically enabled for every tenant or role.

CentaurNexus carries this contract into onboarding. Each supported workflow defines which resource must be read or changed, which role is required and how the state can later be verified through read-back. Broad scopes are not a substitute for precise assignment.

ZIA, ZPA and ZDX remain important but not exclusive contexts

ZIA contributes internet, SaaS, URL, firewall and DLP-related work contexts. ZPA covers private applications, segments, connectors, access and PRA-related workflows. ZDX provides digital-experience signals across device, application and network path. These three areas shape many daily support and administration cases.

ZCC, ZTW, ZIdentity, EASM, Z-Insights and ZMS can add further building blocks. Availability for a tenant depends on licence, service linkage, API role, technical source and the supported CentaurNexus workflow.

The help desk needs a user context, not a collection of portals

A support case can involve device, Client Connector, web access, private application and digital experience at the same time. The help desk should not have to collect these details manually from several consoles. User Support Center and Unified Support Center combine the context permitted for the role.

About 70 data points in the user context does not mean that every value is guaranteed for every tenant. Source, freshness and coverage show which components are actually present. The operator gets a connected finding and can recognise missing areas.

Administrators need rules and their dependencies

For administration and second level, an object list alone is insufficient. Rules can contain includes, excludes, order, groups, tunnels, approvals and other relationships. CentaurNexus presents these connections in a shared context for supported workflows.

Write operations remain controlled individual changes. A write is successful only after actual target-system effect and read-back. The shared interface therefore remains connected to the authority of the Zscaler target system.

Security, MSPs and management see different views

Security needs reports, URL assessments, approval status and visible data sources. MSPs need clear customer and tenant context for repeatable workflows. Management needs aggregated trends, responsibilities and coverage without receiving operational detail rights.

A shared platform therefore does not mean one identical interface for everyone. Role paths use the same underlying workflow while exposing only the information and actions intended for the task.

OneAPI and feed sources complement each other

OneAPI primarily answers questions about current configuration and status. NSS and LSS feeds add observed access, sessions and rule activity across the available history. Many meaningful analyses require both layers.

OneAPI, NSS and LSS provide complementary configuration, status and history context. CentaurNexus identifies the source of each result and shows the available coverage.

Onboard with a coverage matrix

  1. Inventory licensed Zscaler domains and linked services.
  2. Prioritise role paths and concrete workflows.
  3. Map required API resources, roles and scopes.
  4. Add NSS and LSS feeds for historical analysis.
  5. Test read, write and read-back contracts for each workflow.
  6. Accept source, data age and coverage in the role interfaces.

The coverage matrix turns an abstract domain list into a reviewable operating contract. It shows which workflow uses which source and which tenant prerequisite must be met.

The multi-vendor contract seam remains prepared

The 1.0 contracts separate domain workflow, provider adapter and confirmed target state. A further provider source can therefore be added later through its own evidenced contract without redefining OneAPI or Zscaler domain logic.

The concrete second provider is not decided. The prepared seam is not a claim for a named third-party platform today. Zscaler remains the core provider for the product state described here.

Maintain coverage during operations

Tenant licences, scopes and linked services can change. A matrix created during onboarding is therefore not a static document. CentaurNexus monitors source state and exposes when a previously available area becomes limited or a new domain becomes usable.

Coverage changes are reviewed against affected role paths. A missing scope must not silently produce empty results. At the same time, an independent workflow remains available when its source continues to be valid.

Platform operations as a distinct persona

Platform operations does not own every customer domain decision. It ensures that adapters, source contracts, tenant isolation and technical states work reliably. This role needs health, error and version information without universal access to all customer domain data.

The separation is especially important for MSP and regional operation. Technical maintenance remains possible while customer responsibility and tenant-bound decisions stay with the intended roles.

One operating context across Zscaler domains

Zscaler remains the core provider and target system. CentaurNexus connects supported workflows, roles, approvals, audit, ITSM and read-back into a daily operating context.

The single pane of glass unifies supported Zscaler workflows while the connected services remain the authoritative source and target system.

Frequently asked questions

How does CentaurNexus work with Zscaler portals?

Zscaler remains the core provider. CentaurNexus adds a shared operational, governance and integration layer for supported workflows.

Is OneAPI tenant-dependent?

No. Available domains, licences, scopes and data sources depend on the tenant.

Does CentaurNexus fully cover every Zscaler domain?

Concrete coverage is shown per tenant and workflow.

Sources and further information

See the workflow in context

Choose the relevant role in the demo launcher. The demo uses prepared sample data.

Open demo launcher