Ellipse Gradient for Header

Wiz Integration Guide

Connect Wiz cloud security findings and inventory to enterprise systems through its GraphQL API and OAuth 2.0 service-account authentication.

Wiz integration options at a glance

Wiz provides a GraphQL-first public API for querying Issues, Vulnerabilities, Cloud Resources, Cloud Accounts, Projects, and Controls. API access uses OAuth 2.0 credentials associated with a Wiz service account and bearer tokens on GraphQL requests. Martini can acquire and refresh tokens, submit parameterized queries, paginate through bounded result sets, and map the responses into applications, databases, files, or APIs. A general-purpose Wiz webhook, outbound callback, REST API, bulk API, file API, or direct database interface was not confirmed. For dependable recurring synchronization, use scheduled Martini workflows with supported filters, timestamps, status fields, checkpoints, retries, and idempotent target writes.

Integration pointSupported by Wiz?Common use casesHow Martini supports it
GraphQL APIsYesQuery Issues, Vulnerabilities, Cloud Resources, Cloud Accounts, Projects, Controls, and related security data using queries, variables, filters, and pagination.Martini can consume the Wiz GraphQL API from workflows, submit parameterized requests, transform responses, and route results to applications, databases, files, or APIs.
AuthenticationYesAuthenticate API requests with OAuth 2.0 client credentials associated with a Wiz service account and bearer access tokens.Martini can obtain tokens in a workflow and store client credentials in secrets or environment configuration rather than embedding them in mappings or logs.
Scheduled synchronizationYesRun recurring GraphQL queries for changed or qualifying findings, resources, projects, or controls when a verified event mechanism is unavailable.Martini can schedule workflows, maintain checkpoints, paginate through results, and apply controlled retries and backoff.
Webhooks / outbound callbacksNot confirmedA general-purpose Wiz webhook or callback stream for all object changes was not confirmed; product-specific notifications require separate verification.Martini can receive webhooks when a specific Wiz capability is verified, but the default design should use scheduled GraphQL synchronization.
Bulk / async / batch APIsNot confirmedA separate Wiz bulk or asynchronous public API was not confirmed. Large result sets can be processed through GraphQL pagination and workflow-level batching.Martini can process pages in controlled batches and persist checkpoints without representing that pattern as a Wiz bulk endpoint.
File / attachment APIsNot confirmedNo general-purpose Wiz file or attachment API was confirmed; product-specific reports or exports require verification.Martini can process files when a verified export is available, but should use the Wiz GraphQL API for the default integration.
Database / analytics accessNot confirmedDirect access to Wiz operational data was not confirmed, so integrations should not depend on a Wiz database connection.Martini can write normalized Wiz data to supported SQL databases after retrieving it through GraphQL.
REST APIsNot confirmedA primary Wiz REST API was not confirmed; the documented public integration interface is GraphQL-first.Martini can consume REST APIs for adjacent target systems, while Wiz access should be designed around its confirmed GraphQL API.

How Wiz exposes data and business events

Wiz GraphQL APIs

Wiz's principal public integration mechanism is a GraphQL API. It provides access to security and cloud data such as Issues, Vulnerabilities, Cloud Resources, Cloud Accounts, Projects, and Controls, subject to the service account's permissions and the current schema.

Martini implementation pattern

Martini implementation pattern: a workflow acquires an OAuth 2.0 bearer token, submits a narrow GraphQL query with variables, follows schema-supported pagination, validates HTTP and GraphQL responses, and maps the returned objects to the target model.

Implementation sequence

Acquire an OAuth 2.0 access token for the Wiz service account
Submit the GraphQL query with variables and the bearer token
Retrieve each result page using the supported cursor or pagination fields
Validate HTTP responses, GraphQL errors, and authorization results
Map Wiz objects to the canonical integration model
Write the result to the target system and store the synchronization checkpoint

Scheduled Wiz synchronization

A general-purpose Wiz webhook or outbound callback stream was not confirmed. Scheduled queries with timestamps, status fields, filters, and pagination are therefore the dependable default for recurring synchronization.

Martini implementation pattern

Martini implementation pattern: a scheduler starts a workflow, the workflow reads its prior checkpoint, queries only the relevant Wiz scope, processes pages in bounded batches, and records successful progress for the next run.

Implementation sequence

Start the workflow on a controlled schedule
Load the prior synchronization checkpoint and scope parameters
Query changed or qualifying Wiz objects
Process each page with bounded concurrency and backoff
Apply deduplication and target create-or-update rules
Persist the checkpoint only after successful target writes

Wiz OAuth 2.0 authentication

Wiz API access uses OAuth 2.0 credentials associated with a Wiz service account. The service account's role and permissions determine which projects, cloud accounts, findings, and fields are available.

Martini implementation pattern

Martini implementation pattern: credentials are stored in Martini secrets or environment configuration, a workflow requests an access token, and subsequent GraphQL calls use the token without exposing client secrets in payloads or logs.

Implementation sequence

Create or select a Wiz service account with minimum required permissions
Store the client credentials in Martini secrets or environment configuration
Request an OAuth 2.0 access token
Attach the bearer token to each GraphQL request
Refresh the token when required
Handle authentication and authorization failures separately

Common Wiz integration patterns

Pattern 1: Sync Wiz Issues to ServiceNow

When to use this pattern

Use this pattern when security operations teams need Wiz findings represented as ServiceNow incidents, security incidents, or remediation tasks. It supports recurring synchronization of new and changed Issues while preserving Wiz identifiers and audit context.

Integration direction
Wiz
Martini
ServiceNow
Example Mapping
Wiz FieldCanonical FieldTarget Field
Issue.idsourceFindingIdcorrelation_id
Issue.severityseveritypriority
Issue.statusfindingStatusstate
Issue.projectprojectContextassignment_group
Martini implementation pattern

A scheduled workflow obtains a token, queries changed Issues by supported filters, enriches and validates the result, then performs idempotent ServiceNow create-or-update calls. Stable external identifiers prevent duplicates, while retries and a failed-item path handle target failures.

Martini capabilities used
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling
  • scheduled execution

Pattern 2: Route Wiz Vulnerabilities to Jira

When to use this pattern

Use this pattern when engineering or security teams manage remediation in Jira and need actionable Wiz Vulnerabilities converted into traceable work items. Severity, project, cloud account, and status can determine routing and priority.

Integration direction
Wiz
Martini
Jira
Example Mapping
Wiz FieldCanonical FieldTarget Field
Vulnerability.idsourceVulnerabilityIdExternal reference
Vulnerability.severityseverityPriority
Vulnerability.statusfindingStatusStatus
Vulnerability.projectprojectContextProject
Martini implementation pattern

Martini queries qualifying Vulnerabilities, applies routing and severity rules, maps security context into Jira fields, and checks the source identifier before creating or updating an issue. Repeated scan results are deduplicated and transient failures are retried with bounded backoff.

Martini capabilities used
  • workflows
  • GraphQL API consumption
  • data mapping
  • business rules
  • deduplication
  • retry handling

Pattern 3: Maintain a Wiz cloud-security inventory

When to use this pattern

Use this pattern when a reporting or analytics estate needs normalized Cloud Resources, Cloud Accounts, Projects, Issues, and Controls. It is suitable for scheduled incremental loads into a SQL database or data warehouse.

Integration direction
Wiz
Martini
SQL database
Example Mapping
Wiz FieldCanonical FieldTarget Field
CloudResource.idsourceResourceIdsource_resource_id
CloudResource.nameresourceNameresource_name
CloudAccount.idcloudAccountIdcloud_account_id
Project.idprojectIdproject_id
Martini implementation pattern

A scheduled Martini workflow reads a checkpoint, pages through Wiz GraphQL results, transforms nested responses into normalized tables, and writes records to a supported SQL database. Upserts use stable source identifiers, and checkpoints advance only after successful writes.

Martini capabilities used
  • scheduled workflows
  • GraphQL API consumption
  • pagination
  • data mapping
  • SQL database integration
  • checkpointing
  • error handling

Pattern 4: Notify teams about high-severity Wiz findings

When to use this pattern

Use this pattern when teams need selected high-severity Issues, Vulnerabilities, or Control violations delivered to Slack or Microsoft Teams without forwarding every unchanged finding. A specific native Wiz notification stream should not be assumed.

Integration direction
Wiz
Martini
Slack or Microsoft Teams
Example Mapping
Wiz FieldCanonical FieldTarget Field
Issue.severityseverityalertLevel
Issue.idsourceFindingIdexternalReference
Issue.statusfindingStatusmessageContext
Issue.projectprojectContextchannelRouting
Martini implementation pattern

Martini periodically queries qualifying objects, applies severity, status, project, and deduplication rules, aggregates unchanged findings, and invokes the selected collaboration platform's supported API or endpoint. Failed notifications are logged and retried without reprocessing successful deliveries.

Martini capabilities used
  • scheduled workflows
  • GraphQL API consumption
  • business rules
  • data transformation
  • deduplication
  • retry handling

Applications commonly integrated with Wiz

Wiz data can be routed to security operations, engineering, collaboration, observability, and cloud platforms. The following are practical enterprise integration targets; exact vendor-supported integration behavior and target API requirements should be validated for each environment.

Application Scenario Direction Martini Pattern
ServiceNow Convert Wiz Issues into incidents, security incidents, or remediation tasks while synchronizing ownership, severity, and status. Wiz → Martini → ServiceNow A scheduled Martini workflow queries changed Issues, maps stable identifiers and security attributes, and performs idempotent ServiceNow create-or-update operations with retry handling.
Jira Track actionable Wiz Vulnerabilities and Issues through engineering or security remediation workflows. Wiz → Martini → Jira Martini filters findings by severity, project, cloud account, or status, applies deduplication using the Wiz identifier, and calls Jira APIs to create or update issues.
Slack Notify security and cloud teams about selected high-severity findings or policy violations. Wiz → Martini → Slack A scheduled workflow queries qualifying Wiz objects, applies routing and aggregation rules, and sends concise notifications through Slack's supported API or incoming endpoint.
Microsoft Teams Deliver security alerts and summaries to operational teams in existing collaboration channels. Wiz → Martini → Microsoft Teams Martini retrieves qualifying findings, groups unchanged results to prevent notification noise, transforms the message payload, and invokes the required Teams endpoint.
Splunk Centralize Wiz findings with broader security telemetry for correlation, investigation, and reporting. Wiz → Martini → Splunk Martini pages through Wiz results, normalizes finding and cloud context into an ingestion model, and sends batches to the supported Splunk ingestion interface with checkpointing.
Datadog Combine Wiz cloud security findings with infrastructure and operational monitoring data. Wiz → Martini → Datadog A workflow transforms selected Wiz Issues, Vulnerabilities, or resource data into Datadog-compatible events or records and applies bounded retries for transient target failures.
AWS Correlate Wiz findings with AWS accounts, resources, identities, and infrastructure metadata or export normalized results to AWS-based systems. Wiz → Martini → AWS Martini queries Wiz cloud context, preserves account and resource identifiers, and writes normalized data to the required AWS-based API, database, or storage interface after validation.
Microsoft Azure Correlate Wiz findings with Azure subscriptions, resources, and identities or route normalized security data to Azure-based systems. Wiz → Martini → Microsoft Azure Martini retrieves Wiz objects with project and cloud-account context, maps Azure identifiers and security attributes, and delivers the result to the selected Azure-based endpoint.

How to build a Wiz integration in Martini

Objective

Establish Wiz access using a service account and OAuth 2.0 client credentials with the minimum permissions required for the selected objects and scope.

Instructions in Martini

  • Create or select the required Wiz service account
  • Store the client ID and secret in Martini secrets or environment configuration
  • Configure the token request and bearer-token handling
  • Test authentication separately from object authorization

Objective

Select scheduled execution as the default trigger because a general-purpose Wiz webhook or callback mechanism was not confirmed.

Instructions in Martini

  • Use a scheduler for recurring synchronization
  • Define the frequency according to data freshness and tenant limits
  • Use a verified Wiz event capability only if it is confirmed for the required event
  • Set an explicit tenant, project, and cloud-account scope

Objective

Use narrow, schema-confirmed GraphQL queries to retrieve the required Wiz objects and process bounded result pages.

Instructions in Martini

  • Define GraphQL queries and variables against the current Wiz schema
  • Request only fields needed by the integration
  • Implement cursor-based pagination where supported
  • Filter by timestamps, status, severity, project, or other supported fields

Objective

Coordinate token acquisition, page retrieval, validation, transformation, target writes, checkpoints, and failure handling in one maintainable Martini workflow.

Instructions in Martini

  • Separate authentication, retrieval, mapping, and delivery stages
  • Handle HTTP errors, GraphQL errors, permission failures, and target failures distinctly
  • Use controlled concurrency, retry limits, and backoff
  • Preserve source identifiers and synchronization context

Objective

Transform Wiz security and cloud objects into the target model while preserving original values needed for auditability and reconciliation.

Instructions in Martini

  • Map severity, status, project, account, resource, owner, and remediation fields explicitly
  • Validate required target fields before delivery
  • Preserve the original Wiz identifier and source values
  • Apply target-specific rules for routing and prioritization

Objective

Deliver normalized data to applications, databases, collaboration platforms, files, or a Martini-exposed API using idempotent operations.

Instructions in Martini

  • Check for an existing target object using the stable Wiz identifier
  • Create or update the target according to the integration contract
  • Write inventory data using database upserts where appropriate
  • Advance checkpoints only after successful writes

Common Wiz data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
IssuesSecurity findings requiring triage, ownership, remediation, and status tracking.ServiceNow, Jira, Slack, Microsoft Teams, SplunkMartini queries changed or qualifying Issues, preserves the Wiz identifier, maps severity and status, and performs idempotent target updates.
VulnerabilitiesVulnerability findings associated with workloads, images, packages, or related security context.Jira, ServiceNow, Splunk, DatadogMartini filters by severity, project, cloud account, or status, transforms vulnerability context, and applies deduplication before delivery.
Cloud ResourcesCloud assets discovered and assessed by Wiz.SQL databases, data warehouses, Splunk, AWS, Microsoft AzureMartini paginates resource queries, retains cloud-account and project context, normalizes fields, and writes checkpoints with the inventory data.
Cloud AccountsConnected AWS, Microsoft Azure, Google Cloud, or other cloud-account contexts.SQL databases, reporting platforms, Splunk, DatadogMartini maps account identifiers and tenant context into an inventory model and uses them to scope or enrich finding synchronization.
ProjectsWiz organizational groupings used to scope resources, ownership, and security management.ServiceNow, Jira, SQL databases, reporting platformsMartini preserves project scope and ownership attributes while routing findings and inventory to target systems.
ControlsSecurity or compliance checks used to evaluate cloud environments against policies or frameworks.Splunk, Datadog, SQL databases, collaboration platformsMartini retrieves control results, applies business rules for violations or changes, and publishes normalized compliance data.

Authentication and security considerations

OAuth 2.0 service accounts

Wiz API access uses OAuth 2.0 credentials associated with a Wiz service account. The service account's role and permissions govern access to projects, cloud accounts, findings, and fields.

Secret handling

Store Wiz client credentials and target-system credentials in Martini secrets or environment configuration. Do not embed secrets in workflows, mappings, payloads, or logs.

Least privilege and scope

  • Grant only the permissions required for the selected Wiz objects and operations.
  • Test token acquisition separately from authorization to specific projects and cloud accounts.
  • Preserve tenant, project, and cloud-account context in downstream records.

Operational considerations for Wiz integrations

Pagination and throttling

Use schema-supported cursor pagination and bounded batches. Control request rates, apply limited retries with backoff, and confirm current Wiz limits for the tenant and service-account plan.

Incremental synchronization

Prefer supported timestamp, status, or other filters and persist a checkpoint after successful target writes. Do not treat absence from one incremental response as deletion.

Idempotency and reconciliation

Use stable Wiz identifiers for Issues, Vulnerabilities, Cloud Resources, and related objects. Define mappings for open, closed, resolved, suppressed, and remediated states before writing to targets.

Schema and testing

Keep GraphQL queries narrow and confirm types, fields, filters, and mutations against the current Wiz schema. Test permissions, pagination, partial failures, target retries, and schema changes in a controlled environment.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate the complete integration

Martini coordinates OAuth token acquisition, GraphQL requests, pagination, transformations, business rules, target calls, checkpoints, and error handling in maintainable workflows rather than scattering logic across scripts.

Adapt to enterprise data models

Wiz security and cloud objects rarely map directly to ServiceNow, Jira, databases, or collaboration platforms. Martini provides explicit mappings, validation, enrichment, routing, and idempotent delivery while preserving source context.

Expose controlled APIs

Martini can expose a REST API that normalizes selected Wiz data for downstream consumers, applying authorization and business rules without requiring each consumer to understand the Wiz GraphQL schema.

Improve operations

Reusable workflows, secure configuration, scheduled execution, logging, retries, and checkpointing provide a more consistent operational model than isolated point-to-point scripts.

Frequently asked questions

How can Wiz be integrated with enterprise systems?

Wiz is integrated primarily through its GraphQL API. Enterprise workflows authenticate with OAuth 2.0 service-account credentials, query objects such as Issues, Vulnerabilities, Cloud Resources, Cloud Accounts, Projects, and Controls, paginate through results, and map them into applications, databases, reporting platforms, or collaboration tools. A general-purpose webhook, REST, bulk, file, or database interface was not confirmed.

Can Martini integrate with Wiz?

Yes. Martini can integrate with Wiz by acquiring OAuth 2.0 bearer tokens, consuming the Wiz GraphQL API, applying pagination and filters, transforming Wiz objects, and delivering them to target applications or databases. Martini can also expose a controlled REST API for normalized Wiz data.

Do I need a connector to integrate Wiz with Martini?

No. A dedicated Wiz connector is not required. Martini can use Wiz's confirmed native integration mechanisms: its GraphQL API and OAuth 2.0 service-account authentication. Webhooks or callbacks should only be used if the required Wiz capability is separately verified.

Is there any extra Lonti cost to integrate Wiz with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Wiz with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Wiz, infrastructure providers, or other third-party systems based on subscriptions, usage, and deployment model.

Which Wiz integration method should be used?

Use the Wiz GraphQL API as the primary integration method, together with OAuth 2.0 service-account authentication. Design queries around the current schema, supported filters, variables, and pagination. Do not assume a primary Wiz REST API or SOAP API.

Does Wiz provide webhooks or event notifications?

A general-purpose Wiz webhook or outbound callback stream for all Issues, Vulnerabilities, or resource changes was not confirmed. Product-specific notification mechanisms may exist, but they should be verified for the required event. Scheduled GraphQL synchronization is the default reliable approach.

How does Martini synchronize Wiz data and avoid duplicates?

Martini can run scheduled GraphQL queries using supported timestamps, statuses, filters, and pagination, then store checkpoints for incremental processing. Stable Wiz identifiers should be retained as external keys, with idempotent create-or-update logic and explicit reconciliation rules for closed, resolved, suppressed, or no-longer-returned findings.

How does Martini handle Wiz mapping, errors, and schema changes?

Martini maps Wiz fields into a canonical or target model, applies explicit severity and status rules, validates required data, and handles OAuth, HTTP, GraphQL, permission, and target-system failures separately. Bounded retries and backoff address transient errors. Queries should remain narrow and schema-confirmed because fields and types can evolve.