What is Zscaler OneAPI?
Zscaler OneAPI is the unified API access point for the Zscaler platform, used to read and control services' configuration and operational data programmatically. Instead of separate product APIs each with their own login, OneAPI bundles access to services such as ZIA, ZPA and ZDX behind one shared entry point; authentication runs centrally through ZIdentity with OAuth 2.0. Integrations, automations and operations cockpits build on top of it to bring information together, generate reports, or carry out changes in a controlled way. OneAPI is therefore the technical foundation for embedding Zscaler operations into your own processes and tools, without maintaining separate interface logic for every service.
Zscaler OneAPI in detail
Historically, every Zscaler product had its own API with its own authentication method: ZIA with an API key and admin login, ZPA with a client ID and secret. OneAPI unifies this: an API client is registered centrally in ZIdentity and obtains OAuth 2.0 tokens, which it uses to call the services it has been granted access to. The assigned permissions (scopes) control which areas a client may read or write. The previous product APIs continue to exist and are still documented as their own section in the Zscaler Help Portal, but for new integrations, OneAPI is the path Zscaler intends you to use.
Typical use cases include reading user, device and policy data, generating reports, and controlled automation of recurring changes. Like any cloud API, OneAPI is subject to rate limits that integrations need to plan for. The usual rules apply for secure operation: grant API clients access on a least-privilege basis, store and rotate secrets securely, and log every write automation in a traceable way.
Why OneAPI matters in Zscaler operations
In operations, the API layer determines how well Zscaler fits into existing processes. Recurring questions such as 'which policy applies to this user?' or 'which devices are reporting problems?' can only be answered manually through the console. With OneAPI, tools can pull this information automatically and prepare it, for example for ticketing systems, reports or a support view. The decisive effect: staff get answers without anyone having to hand out privileged console access for it.
At the same time, API access is itself privileged access and needs to be governed: which API clients exist, who holds the credentials, which scopes have been granted, and which changes went through the interface? For evidence under NIS2 or DORA, the API layer counts just as much as the console. Unused or over-privileged API clients are a quiet risk item that regular reviews should catch.
Common sources of error
- Over-privileged API clients: a client with full access for a purely read-only use case violates least privilege and increases the damage if a secret leaks.
- Secrets in plain text: API credentials in scripts, repositories or tickets instead of a secret store undermine the entire access control model.
- Ignoring rate limits: aggressive polling runs into rate limits and makes integrations unreliable, often exactly during peak times.
- Mixed old and new integrations: running legacy APIs and OneAPI connections in parallel with no plan leads to duplicated maintenance and inconsistent data.
OneAPI in practice: how CentaurNexus builds on it
For CentaurNexus, OneAPI is the foundation: the platform builds on Zscaler OneAPI and brings together the view of ZIA, ZPA and ZDX as a sovereign single pane of glass. User Support Center gives the helpdesk a 360-degree user finding in one view, without handing out Zscaler admin rights. The guide below describes how that changes day-to-day support: Zscaler support without admin rights. Access uses only API credentials provided by the customer, every write action is auditable, and changes can be approved under the four-eyes principle. Hosting is in Germany, GDPR-compliant: operational and evidence data stay in the EU.
Related terms
Frequently asked questions about Zscaler OneAPI
Previously, every product had its own API with its own sign-in method, for example ZIA with an API key and ZPA with a client ID and secret. OneAPI bundles access behind one shared entry point with central OAuth 2.0 authentication through ZIdentity. That simplifies integrations and makes permissions and token management controllable in one consistent way.
Authentication runs through ZIdentity: an API client is registered there, obtains OAuth 2.0 tokens, and uses them to call the services it has been granted access to. The assigned permissions determine which data the client may read or change. The credentials belong in a secret store and should be rotated regularly.
OneAPI covers core services of the Zscaler platform, including ZIA, ZPA and ZDX. The exact feature scope per service and endpoint keeps evolving and is described in the official API documentation in the Zscaler Help Portal. For new integrations, OneAPI is the intended access point.
Yes, depending on the permissions granted, both read and write access are possible, for example adjusting policies and configurations. That is exactly why the following applies: grant scopes on a least-privilege basis, log write automation, and secure critical changes with an approval process such as the four-eyes principle.
No. The console remains the tool for interactive administration. OneAPI adds the programmatic path alongside it: automation, reports, integrations into ticketing systems or operations cockpits. A sensible division of labour is to handle recurring reporting and controlled workflows through the API, and special cases in the console.
- Zscaler Help Portal: OneAPI documentation - help.zscaler.com/oneapi
- Zscaler Help Portal, help.zscaler.com
- Zscaler Help Portal: What Is Authentication Service? (formerly ZIdentity) - help.zscaler.com/zidentity/what-zidentity
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.