.png)
Zscaler Integration Guide
Integrate Zscaler security services with enterprise systems through product-specific REST APIs, authenticated workflows, polling, and supported log or notification delivery mechanisms.
Zscaler integration options at a glance
Zscaler integrations are primarily built around product-specific REST APIs for Zscaler Internet Access (ZIA), Zscaler Private Access (ZPA), Zscaler Digital Experience (ZDX), and related services. ZIA commonly uses an administrator session established with credentials and an API key, while ZPA commonly uses OAuth-style client credentials and bearer tokens. Martini can schedule polling of configuration, reporting, and audit endpoints, consume supported log-streaming or notification mechanisms, and orchestrate product-specific bulk operations where available. It can normalize JSON payloads, maintain pagination and synchronization checkpoints, apply policy rules, and expose controlled APIs for downstream systems.
| Integration point | Supported by Zscaler? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | ZIA, ZPA, ZDX, and other Zscaler services expose product-specific REST APIs for configuration, policy management, reporting, monitoring, and operational data. | Martini can consume HTTPS REST APIs from workflows, generate reusable API assets from external definitions where applicable, map JSON payloads, apply business rules, and expose normalized APIs. |
| Authentication | Yes | ZIA commonly establishes an authenticated administrator session using credentials and an API key. ZPA commonly uses OAuth-style client credentials and bearer tokens; other services may use product-specific token schemes. | Martini can store credentials and secrets by environment, obtain or refresh sessions and tokens, and separate authorization failures from transient API failures. |
| Webhooks / outbound callbacks | Not confirmed | A vendor-wide webhook model was not confirmed. Some Zscaler services may provide product-specific notification features that require separate verification. | Martini can receive a supported callback when the relevant Zscaler service documents one, but workflows should otherwise use polling or supported log delivery. |
| Bulk / async / batch APIs | Limited | Selected Zscaler product APIs may provide bulk or batch behavior for administrative configuration, but there is no confirmed uniform model across services. | Martini can orchestrate endpoint-specific batches, bound concurrency, handle partial results, and apply retries according to the documented operation semantics. |
| Database / analytics access | Limited | Analytics and operational data can be obtained through reporting, monitoring, ZDX, or log-streaming capabilities. Direct database access is not the normal Zscaler integration method. | Martini can consume reporting APIs or log streams, normalize results, maintain checkpoints, and write the data to a database or downstream analytics platform. |
| Log and event streaming | Limited | Security logs may be delivered through capabilities such as Nanolog Streaming Service where licensed and configured. Availability, retention, latency, and object coverage vary by product and tenant. | Martini can process supported inbound streams or retrieve event data incrementally, normalize records, deduplicate deliveries, and route them to SIEM or operational systems. |
| SDKs and client libraries | Limited | Zscaler and third parties provide client libraries or infrastructure-as-code integrations for some products, but REST APIs are the most portable integration surface. | Martini does not require an SDK when the applicable API is accessible over HTTPS; custom JVM-compatible logic can be used when a documented edge case requires it. |
| File / attachment APIs | Not confirmed | No general Zscaler file or attachment API was confirmed. Integrations are primarily based on JSON REST APIs, reporting endpoints, and log or event streams. | Martini can process files when another system supplies them, but a Zscaler file or attachment mechanism should not be assumed. |
How Zscaler exposes data and business events
Zscaler REST APIs
Zscaler provides separate REST API surfaces for products such as ZIA, ZPA, ZDX, and related services. These APIs support administrative configuration, policy management, reporting, monitoring, and operational data, but endpoint paths, objects, authentication, and API versions vary by product and tenant.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates against the selected Zscaler product, calls the required REST endpoints, handles pagination and product-specific responses, maps payloads into a canonical model, and writes results to downstream systems or exposes them through a controlled Martini API.
Implementation sequence
Zscaler Polling and Reporting
Zscaler integrations commonly use scheduled polling of configuration, reporting, audit, and operational endpoints when a required event is not available as a callback. Incremental filters, timestamps, cursors, or Martini-side synchronization state can reduce repeated full extraction.
Martini implementation pattern
Martini implementation pattern: a scheduled workflow retrieves only the relevant time window or changed objects, persists a checkpoint, normalizes the results, and routes them to systems such as ServiceNow, a SIEM, or a data store. The workflow can distinguish an empty result from a failed request and resume safely after interruption.
Implementation sequence
Zscaler Log Streaming
Some Zscaler services can provide security or operational log delivery through capabilities such as Nanolog Streaming Service when licensed and configured. This is not a universal event mechanism, and availability, retention, latency, and object coverage depend on the product and tenant.
Martini implementation pattern
Martini implementation pattern: when a supported stream or delivery path is available, Martini receives or consumes the event data, validates the payload, maps it to a common event model, and forwards it to a SIEM or durable processing target. Filtering, batching, deduplication, and backpressure are important for high-volume telemetry.
Implementation sequence
Zscaler Notifications and Callbacks
A vendor-wide webhook model was not confirmed. Individual Zscaler services may document notification or outbound callback features for selected events, so coverage must be verified for the specific product, tenant, and event type.
Martini implementation pattern
Martini implementation pattern: if the required callback is documented, Martini exposes a controlled API endpoint to receive it, validates the source and payload, retrieves current Zscaler state when necessary, and starts an asynchronous workflow. If no callback exists, the same workflow can be triggered by a scheduler or reporting poll.
Implementation sequence
Common Zscaler integration patterns
Pattern 1: Reconcile Zscaler policy changes with ServiceNow
When to use this pattern
Use this pattern when security and IT operations teams need an auditable view of changes to ZIA URL Filtering Rules, Firewall Filtering Rules, Locations, or ZPA Application Segments. Scheduled polling is appropriate when a product-specific callback is not available.
Integration direction
Example Mapping
| Zscaler Field | Canonical Field | Target Field |
|---|---|---|
| objectId | securityObject.externalId | Configuration item or record external ID |
| name | securityObject.name | Name |
| modifiedTime | securityObject.updatedAt | Updated |
| action | change.action | Change type |
Martini implementation pattern
A scheduled Martini workflow authenticates to the relevant Zscaler API, retrieves paginated changes, compares them with a stored baseline, and applies idempotent ServiceNow creates or updates. It validates policy dependencies, uses stable identifiers to avoid duplicates, and routes rate-limit or transient failures to retry handling while preserving the last successful checkpoint.
Martini capabilities used
- workflows
- scheduled triggers
- API consumption
- pagination and checkpointing
- data mapping
- business rules
- error handling
Pattern 2: Synchronize identity lifecycle changes to Zscaler
When to use this pattern
Use this pattern for joiner, mover, and leaver processes in which Okta or Microsoft Entra ID changes should influence Zscaler administrative access, group relationships, application access, or policy configuration.
Integration direction
Example Mapping
| Zscaler Field | Canonical Field | Target Field |
|---|---|---|
| user.id | identity.externalId | Admin User or access subject ID |
| user.status | identity.lifecycleStatus | User status |
| groups | identity.groups | Group or policy association |
| department | identity.organizationUnit | Application or policy attribute |
Martini implementation pattern
Martini receives or polls directory changes, validates the identity and group mapping, resolves dependent Zscaler objects, and calls the relevant ZIA or ZPA REST API. Business rules can require approval for privileged changes, while authorization failures are quarantined rather than retried and successful operations are audit logged.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- secrets management
- audit logging
- error handling
Pattern 3: Route Zscaler security telemetry to a SIEM
When to use this pattern
Use this pattern when security teams need Zscaler audit, proxy, security, or operational data in Splunk or Microsoft Sentinel for centralized detection, compliance reporting, and incident investigation.
Integration direction
Example Mapping
| Zscaler Field | Canonical Field | Target Field |
|---|---|---|
| eventTime | event.timestamp | TimeGenerated or event time |
| eventType | event.category | Event category |
| sourceIp | network.sourceIp | Source IP |
| userName | principal.name | User or principal |
Martini implementation pattern
Martini consumes the applicable reporting API or supported log stream, filters by time window or cursor, transforms payloads into the target SIEM schema, and sends bounded batches. It stores delivery checkpoints, deduplicates repeated events, and retries transient delivery failures without replaying acknowledged batches.
Martini capabilities used
- workflows
- API consumption
- event processing
- JSON transformation
- batching
- deduplication
- retry handling
Pattern 4: Govern ZPA application access
When to use this pattern
Use this pattern when an organization needs to reconcile CMDB ownership, directory entitlements, and ZPA Application Segments, Segment Groups, App Connectors, or Access Policies during access reviews and stale-access remediation.
Integration direction
Example Mapping
| Zscaler Field | Canonical Field | Target Field |
|---|---|---|
| application.id | application.externalId | Application Segment ID |
| owner | application.owner | Segment owner or governance record |
| entitlements | access.entitlements | Access Policy association |
| connectorGroup | application.connectorGroup | App Connector or Segment Group |
Martini implementation pattern
A Martini workflow extracts source ownership and entitlement data, matches it to ZPA objects using stable identifiers, validates dependency and policy ordering, and applies only approved changes. It can perform a reverse reconciliation to identify drift, while failed dependent updates trigger controlled compensation or a review queue.
Martini capabilities used
- scheduled workflows
- API orchestration
- data mapping
- validation
- business rules
- dependency management
- error handling
Applications commonly integrated with Zscaler
Zscaler data is commonly connected with identity, IT operations, security operations, observability, and workflow platforms. The exact product, tenant, licensing, and ingestion path should be validated for each implementation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Track Zscaler policy changes, access events, alerts, and configuration items in operational workflows and change-management processes. | Zscaler → Martini → ServiceNow | A scheduled Martini workflow retrieves ZIA or ZPA changes, normalizes object identifiers and timestamps, and performs idempotent ServiceNow updates. Approved ServiceNow changes can optionally be validated and sent back to Zscaler through its applicable REST API. |
| Splunk | Centralize Zscaler security, audit, proxy, and access telemetry for search, correlation, detection, and investigations. | Zscaler → Martini → Splunk | Martini polls reporting or audit endpoints, or processes an available Zscaler log-streaming feed, then maps events to the target Splunk ingestion model. Checkpoints, filtering, deduplication, and retry handling control telemetry volume. |
| Microsoft Sentinel | Send Zscaler security and audit data to Microsoft’s cloud SIEM for incident correlation and investigation. | Zscaler → Martini → Microsoft Sentinel | A Martini workflow retrieves or receives supported Zscaler event data, transforms it into the agreed Sentinel ingestion format, and sends batches with correlation identifiers and checkpointed delivery state. |
| CrowdStrike Falcon | Correlate endpoint detections with Zscaler web, private-access, and security-policy context during security operations investigations. | Zscaler → Martini → CrowdStrike Falcon | Martini enriches selected Zscaler events with Falcon-related identifiers or forwards normalized telemetry to the security operations process. Product-specific APIs and the required direction of enrichment should be confirmed before deployment. |
| Okta | Use identity and group lifecycle changes to govern Zscaler access, administrative controls, and joiner, mover, and leaver processes. | Okta → Martini → Zscaler | Martini receives or polls Okta changes, validates identity and group mappings, and calls the relevant Zscaler API to update access or policy-related objects. Results and failures are recorded for audit. |
| Microsoft Entra ID | Use directory groups and identity lifecycle events to manage Zscaler access and administrative processes. | Microsoft Entra ID → Martini → Zscaler | A Martini workflow consumes directory changes, resolves the target Zscaler product and object dependencies, and applies controlled REST updates with validation, retries for transient failures, and audit logging. |
| Jira | Create security, access-management, and policy-review work items from Zscaler changes, exceptions, or reconciliation results. | Zscaler → Martini → Jira | Martini polls Zscaler configuration or audit data, applies rules for actionable changes, and creates or updates Jira issues through its REST API using stable Zscaler identifiers to prevent duplicates. |
| Datadog | Correlate Zscaler availability, user-experience, or operational measurements with broader observability data. | Zscaler → Martini → Datadog | Martini retrieves applicable ZDX or operational measurements, maps them to Datadog metrics or event payloads, and applies filtering and batching so high-volume telemetry does not overwhelm a single workflow execution. |
How to build a Zscaler integration in Martini
Objective
Identify the target Zscaler product and tenant, then configure the product-specific API base URL and authentication without embedding secrets in workflow definitions.
Instructions in Martini
- Select ZIA, ZPA, ZDX, or another documented Zscaler service
- Store tenant URLs, credentials, API keys, client secrets, and tokens in environment-specific secrets
- Implement session creation for ZIA or OAuth-style token acquisition for ZPA where applicable
- Define separate handling for authentication, authorization, and transient API failures
Objective
Select a trigger that matches the available Zscaler integration mechanism and the required freshness of the data.
Instructions in Martini
- Use a scheduler for configuration, reporting, and audit polling
- Use a supported callback only after verifying product-specific notification coverage
- Use an available log-streaming mechanism for high-volume security telemetry
- Define the synchronization window, cursor, or checkpoint strategy
Objective
Call the documented Zscaler endpoints and retrieve complete, bounded result sets while respecting product-specific API behavior.
Instructions in Martini
- Call the applicable REST API endpoint
- Handle pagination, cursors, time windows, and endpoint-specific limits
- Persist intermediate state for long-running or incremental synchronizations
- Avoid logging passwords, API keys, client secrets, cookies, or bearer tokens
Objective
Coordinate retrieval, validation, enrichment, target writes, and checkpoint management as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, extraction, transformation, and delivery stages
- Use conditional routing for empty results, invalid data, and authorization failures
- Resolve object dependencies before updating policies or related Zscaler objects
- Use reusable workflow logic for common API and retry behavior
Objective
Convert Zscaler product-specific JSON into a canonical security, identity, IT operations, or event model before delivering it to another system.
Instructions in Martini
- Map actual objects such as Locations, URL Filtering Rules, and Application Segments
- Normalize identifiers, timestamps, status values, and event categories
- Apply field validation and tolerate additive response fields where safe
- Enrich payloads with source-system and correlation metadata
Objective
Ensure that policy, access, and telemetry changes satisfy organizational controls before they are written to target systems or back to Zscaler.
Instructions in Martini
- Require approval for privileged or high-impact policy changes
- Validate references to groups, locations, connectors, and application segments
- Use stable identifiers and idempotent upserts
- Check policy ordering and dependent-object requirements before activation
Common Zscaler data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Locations | Represent ZIA network, office, or access locations used in configuration and policy context. | ServiceNow, CMDBs, identity platforms, security operations systems | Martini retrieves or updates Locations through the applicable ZIA REST API, maps stable identifiers and status fields, and performs idempotent synchronization with pagination and checkpoints. |
| Location Groups | Group ZIA Locations for policy assignment, reporting, or administrative organization. | ServiceNow, CMDBs, policy governance stores | Martini resolves group dependencies, validates referenced Locations, and applies ordered create or update operations with audit records. |
| Admin Users | Represent ZIA administrative identities and their product permissions. | Okta, Microsoft Entra ID, ServiceNow | Martini can reconcile approved identity lifecycle changes with the relevant ZIA API while protecting credentials and recording authorization results without logging secrets. |
| URL Filtering Rules | Define web access filtering policy in ZIA. | ServiceNow, Jira, governance repositories, SIEM platforms | Martini can poll rules for change tracking or orchestrate approved updates, validating required fields, ordering, dependencies, and duplicate prevention. |
| Firewall Filtering Rules | Define ZIA firewall filtering behavior and security controls. | ServiceNow, Jira, compliance repositories, SIEM platforms | Martini normalizes rule metadata, compares it with an internal baseline, and coordinates controlled updates with validation, retry, and compensating-action logic. |
| Application Segments | Represent ZPA-protected applications and their access configuration. | CMDBs, Okta, Microsoft Entra ID, ServiceNow | Martini reconciles application ownership and entitlement data with ZPA Application Segments, resolving dependencies before applying controlled REST changes. |
Authentication and security considerations
Product-specific authentication
Zscaler authentication depends on the product and API generation. ZIA commonly creates an authenticated administrator session using credentials and an API key, while ZPA commonly uses OAuth-style client credentials and bearer tokens. ZDX and newer services may use product-specific token or OAuth mechanisms.
Credential protection
- Store tenant URLs, usernames, passwords, API keys, client secrets, session values, and tokens in environment-specific Martini secrets.
- Use product and tenant permissions that follow least-privilege principles.
- Refresh sessions or tokens without exposing them in workflow logs or downstream payloads.
- Expose normalized Martini APIs when downstream systems should not receive Zscaler credentials.
Operational considerations for Zscaler integrations
Reliability and scale
- Expect rate limits to vary by product, endpoint, tenant, and subscription; handle HTTP 429 and Retry-After responses.
- Use bounded concurrency, exponential backoff, and separate retry policies for authentication, validation, and server errors.
- Handle pagination and persist checkpoints for large collections such as policy rules, applications, locations, and audit events.
- Use stable object identifiers and idempotent writes so retries do not create duplicate policies, locations, or records.
Policy and schema controls
- Resolve dependent objects and policy ordering before applying changes.
- Validate required fields while tolerating additive response fields where appropriate.
- Test against the specific product, cloud tenant, API version, and subscription configuration.
- Retain correlation IDs, source information, object IDs, and API outcomes without recording secrets.
Telemetry volume
Security and proxy telemetry can be substantially larger than configuration data. Use filtering, batching, checkpointing, and durable downstream processing rather than loading an unbounded result set into one workflow execution.
Why use Martini instead of scripts or point-to-point integrations?
More than a point-to-point script
Martini provides a maintainable orchestration layer for Zscaler integrations. It can authenticate against different Zscaler product APIs, coordinate scheduled polling or supported inbound delivery, transform product-specific JSON, and route results to multiple enterprise systems.
Reusable control and reliability
- Centralize secrets and environment-specific configuration.
- Reuse workflow logic for pagination, token renewal, validation, retries, and checkpointing.
- Apply business rules for approvals, policy dependencies, access governance, and idempotency.
- Expose controlled APIs that shield Zscaler credentials and normalize data for consumers.
- Use workflow logs, error handling, and monitoring to troubleshoot failures without building separate operational tooling for every script.
Frequently asked questions
Zscaler can be integrated primarily through product-specific REST APIs for ZIA, ZPA, ZDX, and related services. Enterprise workflows can poll configuration, reporting, audit, and monitoring endpoints, consume supported log-streaming or product-specific notification mechanisms, and synchronize objects such as Locations, policies, Admin Users, and Application Segments. Authentication varies by product and may use an API-key-based ZIA session or OAuth-style ZPA credentials.
Yes. Martini can integrate with Zscaler by consuming the applicable Zscaler REST APIs, obtaining and refreshing product-specific sessions or OAuth access tokens, processing supported log or notification delivery, and mapping Zscaler data into systems such as ServiceNow, SIEM platforms, identity systems, and CMDBs. No Martini-native Zscaler connector is documented in the supplied material.
No. A dedicated Zscaler connector is not required. Martini can use Zscaler’s confirmed native REST APIs, product-specific authentication methods, scheduled polling, and supported notification or log-delivery mechanisms. The exact workflow depends on whether the target service is ZIA, ZPA, ZDX, or another Zscaler product.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Zscaler. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Zscaler, cloud infrastructure, SIEM platforms, or other third-party services depending on subscriptions, usage, licensing, and deployment model.
REST APIs are the primary and recommended integration method confirmed for Zscaler. ZIA commonly uses an authenticated administrator session, while ZPA commonly supports OAuth-style client authentication. Bulk behavior, reporting interfaces, log streaming, and product-specific notifications may be available for selected services and should be confirmed for the target product and tenant. GraphQL and current SOAP APIs were not confirmed.
A vendor-wide webhook model was not confirmed, so Zscaler should not be described as providing callbacks for every policy, configuration, or security event. Some services may document selected notification features. Where a callback is unavailable, Martini can use scheduled polling of reporting or audit APIs, or consume a supported log-streaming mechanism such as Nanolog Streaming Service where licensed and configured.
Martini can use scheduled or event-driven workflows to retrieve Zscaler objects and events, handle pagination, apply timestamps or cursors, and maintain synchronization checkpoints. It maps product-specific JSON into canonical security, identity, IT operations, or event models, applies validation and business rules, and performs idempotent writes to downstream systems such as ServiceNow, Splunk, Microsoft Sentinel, or a database.
A robust integration separates authentication, authorization, validation, rate-limit, network, and server failures. Martini can retry transient failures with bounded exponential backoff and respect Retry-After responses, while avoiding automatic retries for invalid policy changes or insufficient permissions. Stable Zscaler object IDs, checkpoints, correlation identifiers, and idempotent upserts help prevent duplicate updates. Martini can also expose a controlled API façade that hides Zscaler credentials and presents normalized data to downstream applications.
Related Martini documentation
API Integration
Data Handling
Operations
Connect Zscaler with your enterprise systems
Use Martini to build secure, maintainable Zscaler integrations across REST APIs, identity systems, SIEM platforms, IT operations, and security workflows.