Ellipse Gradient for Header

Cortex XSOAR Integration Guide

Integrate Cortex XSOAR with enterprise systems through versioned REST APIs, selected webhook-style mechanisms, API-key authentication, and Martini workflows.

Cortex XSOAR integration options at a glance

Cortex XSOAR provides versioned REST APIs for creating, searching, updating, and closing Incidents; managing Indicators; retrieving investigation data; monitoring Jobs; and interacting with supported Playbook and automation operations. Selected integrations also support webhook-style ingestion or outbound callbacks, although coverage varies by event and resource. Bulk, asynchronous, file, and entry operations are available for applicable use cases and should be verified against the deployed version. Martini can consume these APIs, receive external alerts through a controlled API, transform payloads, apply validation and business rules, and route results to downstream systems. API keys can be stored securely as Martini secrets.

Integration pointSupported by Cortex XSOAR?Common use casesHow Martini supports it
REST APIsYesCreate, retrieve, search, update, and close Incidents; manage Indicators; retrieve investigation data; monitor Jobs; and invoke supported automation or Playbook operations.Martini can consume the versioned Cortex XSOAR REST API from workflows, map request and response payloads, apply business rules, and expose normalized APIs to downstream applications.
Webhooks and outbound callbacksLimitedSelected integrations and incident-ingestion mechanisms can receive HTTP requests or send data to external endpoints. Coverage is not universal for every object or event.Martini can expose an API endpoint or receive webhook-style requests, validate the payload, transform it, and call Cortex XSOAR or another target system.
Bulk, asynchronous, and batch APIsLimitedIncident searches, bulk operations, Jobs, and long-running investigation or automation activity may use bounded batches or asynchronous execution.Martini can filter and batch requests, poll documented Job status, apply backoff, and record checkpoints for resumable processing.
File and attachment APIsLimitedApplicable Incident entries, War Room content, command results, and files can be retrieved or attached through supported operations.Martini can transfer file metadata and content where permitted, enforce size and content rules, and keep evidence handling separate from ordinary Incident mappings.
AuthenticationYesREST API requests generally use an API key in the Authorization header associated with a Cortex XSOAR user and its roles.Martini can store the API key in Secrets Management, apply it to outbound requests, and keep credentials out of workflows, logs, and payload mappings.
Database and analytics accessNoDirect access to the underlying Cortex XSOAR database is not a standard supported integration path; reporting should use supported APIs, searches, or exports.Martini can consume supported REST, search, reporting, or export mechanisms instead of connecting directly to the platform database.

How Cortex XSOAR exposes data and business events

Cortex XSOAR REST APIs

Cortex XSOAR exposes versioned REST APIs for operational, administrative, and automation use cases. The documented resources include Incidents, Indicators, investigations, Jobs, Playbooks, entries, and other product objects, with exact paths and operations dependent on the deployed version.

Martini implementation pattern

Martini implementation pattern: Martini stores the XSOAR base URL and API key securely, receives or retrieves source data, calls the appropriate versioned endpoint, validates the response, maps the result to a canonical model, and routes it to the target system. Endpoint availability, required headers, tenant routing, and permissions are verified during implementation.

Implementation sequence

Authenticate with a least-privilege Cortex XSOAR API key
Receive an alert or retrieve the required XSOAR resource
Apply server-side filters, limits, or pagination
Map the response to the canonical integration model
Apply validation, routing, and business rules
Write the result to the target system and store correlation data

Webhook-style notifications

Cortex XSOAR supports webhook-style ingestion and callbacks for selected integrations and use cases. These mechanisms do not represent a universal outbound webhook for every Incident, Indicator, Playbook, or state change.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled API endpoint for an external security product or receives a supported callback, authenticates and validates the request, checks the source correlation key, and then creates or updates Cortex XSOAR data through the REST API. Where XSOAR sends data outward, Martini validates and normalizes the callback before distributing it.

Implementation sequence

Receive the HTTP notification at a secured Martini API
Authenticate the sender and validate required fields
Normalize the alert or callback payload
Check the source identifier for duplicates
Create or update the Cortex XSOAR Incident when appropriate
Return a correlation response and record the processing outcome

Bulk and asynchronous operations

Selected Cortex XSOAR searches, bulk operations, Jobs, Playbooks, investigations, and automation activities may be bounded, asynchronous, or long-running. Exact behavior is version-dependent and should be confirmed against the target deployment.

Martini implementation pattern

Martini implementation pattern: Martini sends bounded requests using server-side filters, captures Job or execution identifiers, and polls documented status endpoints with timeout, backoff, and retry policies. The workflow records checkpoints so a transient failure does not restart an entire batch.

Implementation sequence

Select a bounded time window or filtered result set
Submit a batch or asynchronous operation
Store the returned Job or execution identifier
Poll the documented status endpoint with backoff
Process completed results in controlled batches
Persist the checkpoint and route failures for review

Entries and file operations

Cortex XSOAR Incidents and War Rooms can contain entries, command results, and files. Supported entry and file operations can retrieve evidence or attach generated content subject to permissions, size, retention, and endpoint constraints.

Martini implementation pattern

Martini implementation pattern: Martini separates Incident metadata from War Room entries and file content, validates content type and size, transfers only the required material, and avoids exposing sensitive evidence in logs or downstream notifications. The workflow records file metadata and correlation identifiers for traceability.

Implementation sequence

Identify the applicable Incident, War Room, entry, or file
Retrieve metadata before transferring content
Validate permissions, size, and content type
Transform or route the approved content
Attach or deliver the result to the target system
Record sanitized metadata and processing status

Common Cortex XSOAR integration patterns

Pattern 1: Normalize alerts into Cortex XSOAR Incidents

When to use this pattern

Use this pattern when security products send alerts in different schemas and Cortex XSOAR should provide a consistent Incident and response workflow. It is suitable for API-led ingestion where duplicate delivery and source-specific severity values must be handled explicitly.

Integration direction
Security product
Martini
Cortex XSOAR
Example Mapping
Cortex XSOAR FieldCanonical FieldTarget Field
source alert IDexternalAlertIdIncident source identifier
alert severityseverityIncident severity
observable valuesindicatorsIncident indicators
alert descriptionsummaryIncident name or details
Martini implementation pattern

Martini receives the alert through an API or selected webhook mechanism, authenticates the sender, validates required fields, normalizes source-specific values, and searches for an existing Incident using the external alert ID. It creates or updates the Incident, returns a correlation ID, and routes validation, authentication, and transient API failures according to separate retry policies.

Martini capabilities used
  • APIs
  • workflows
  • data mapping
  • business rules
  • error handling

Pattern 2: Synchronize Incidents with ServiceNow

When to use this pattern

Use this pattern when security operations and enterprise service management need a shared view of ownership, status, priority, and remediation work. The flow can be bidirectional but should define authoritative fields and update direction for each object.

Integration direction
Cortex XSOAR
Martini
ServiceNow
Example Mapping
Cortex XSOAR FieldCanonical FieldTarget Field
Incident IDsecurityCaseIdcorrelation_id
Incident statuscaseStatusstate
Incident severityprioritypriority
Incident ownerassigneeassigned_to
Martini implementation pattern

A scheduled Martini workflow searches XSOAR for new or changed Incidents using bounded filters, maps them to ServiceNow records, and stores cross-system identifiers. A reverse workflow accepts approved ServiceNow changes, validates state transitions, and updates XSOAR idempotently. Pagination, checkpoints, and retries prevent missed or duplicated updates.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • data mapping
  • conditional routing
  • error handling

Pattern 3: Enrich Indicators with threat intelligence

When to use this pattern

Use this pattern when XSOAR Indicators need reputation, confidence, classification, or contextual data from an external threat-intelligence service before analysts or Playbooks act on them.

Integration direction
Cortex XSOAR
Martini
Threat-intelligence service
Example Mapping
Cortex XSOAR FieldCanonical FieldTarget Field
Indicator valueobservablelookup.value
Indicator typeobservableTypelookup.type
sourceenrichmentProviderresult.provider
confidenceconfidenceScoreresult.confidence
Martini implementation pattern

Martini retrieves eligible Indicators, normalizes case, whitespace, URL encoding, domain representation, or hash format, and calls the enrichment service. It maps confidence and response status back to the appropriate XSOAR Incident, Indicator, or War Room entry while preserving the original value and recording provider and timestamp. Unsupported values and provider timeouts are routed without overwriting source data.

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

Pattern 4: Distribute controlled response results

When to use this pattern

Use this pattern when a Cortex XSOAR Playbook or automation produces a result that must be shared with a ticketing, collaboration, or reporting system without copying the entire investigation or sensitive evidence package.

Integration direction
Cortex XSOAR
Martini
ServiceNow
Example Mapping
Cortex XSOAR FieldCanonical FieldTarget Field
Incident IDcaseIdexternal_case_id
Playbook outcomeresponseStatusresolution_state
War Room summaryresponseSummarywork_notes
completion timecompletedAtresolved_at
Martini implementation pattern

Martini retrieves supported Incident, Job, or War Room information after the operation reaches a documented completion state. It applies data-minimization rules, removes secrets and unnecessary evidence, maps the approved summary to the target system, and retries only transient failures. The workflow records the source execution identifier to prevent duplicate distributions.

Martini capabilities used
  • workflow orchestration
  • API consumption
  • data mapping
  • conditional routing
  • observability

Applications commonly integrated with Cortex XSOAR

Cortex XSOAR commonly participates in security operations architectures that combine alert sources, endpoint platforms, service management tools, collaboration applications, and threat-intelligence systems. Martini can coordinate these systems through reusable workflows while keeping Cortex XSOAR-specific authentication, mappings, retries, and version-dependent API behavior in one integration layer.

Application Scenario Direction Martini Pattern
Splunk Forward security alerts to Cortex XSOAR and distribute incident status or investigation results back to the SIEM. Splunk → Martini → Cortex XSOAR Martini receives or retrieves Splunk alert data, validates the payload, maps detection fields to a Cortex XSOAR Incident, and uses a stable alert identifier for deduplication. A reverse workflow can retrieve selected Incident results and publish normalized status back to Splunk.
Microsoft Sentinel Orchestrate response to Sentinel incidents and synchronize approved investigation or remediation status. Microsoft Sentinel → Martini → Cortex XSOAR A Martini API or scheduled workflow normalizes Sentinel alerts, checks for an existing Cortex XSOAR Incident, and creates or updates it through the REST API. Response status can be mapped back after validating the target schema and permissions.
ServiceNow Create or update security incidents, tasks, and remediation records from Cortex XSOAR cases. Cortex XSOAR → Martini → ServiceNow Martini searches Cortex XSOAR for new or changed Incidents, maps severity, ownership, status, and correlation identifiers to ServiceNow, and processes approved ticket updates back into XSOAR with idempotent workflows.
Jira Track security work, engineering remediation, and vulnerability-related tasks linked to Cortex XSOAR Incidents. Cortex XSOAR → Martini → Jira Martini converts selected Incident fields and War Room summaries into Jira issue payloads, stores the cross-system identifier, and routes status or assignment changes back through validation and explicit field mappings.
Slack Send incident notifications, approvals, and response summaries to security channels. Cortex XSOAR → Martini → Slack After retrieving approved Incident or War Room information, Martini creates a minimized notification payload, removes sensitive evidence, and sends a controlled summary to the appropriate Slack destination. Failures are logged and retried without duplicating notifications.
Microsoft Teams Distribute response notifications and enable analyst collaboration around security incidents. Cortex XSOAR → Martini → Microsoft Teams A Martini workflow retrieves response status from Cortex XSOAR, applies audience and data-minimization rules, and publishes a Teams message or card through the configured endpoint. Correlation data is retained for troubleshooting.
Cortex XDR Transfer endpoint, network, and detection context into Cortex XSOAR for orchestration and automated response. Cortex XDR → Martini → Cortex XSOAR Martini accepts or retrieves Cortex XDR detections, normalizes indicator and alert fields, and creates or updates Cortex XSOAR Incidents. Response outcomes can be returned only when the deployed integrations and permissions support the operation.
CrowdStrike Falcon Enrich investigations with endpoint detections and coordinate containment or response actions. CrowdStrike Falcon → Martini → Cortex XSOAR Martini maps Falcon detections and endpoint context into XSOAR Incidents or Indicators, invokes supported operations where permitted, and records response status with retry and duplicate-event controls.

How to build a Cortex XSOAR integration in Martini

Objective

Establish a version-appropriate Cortex XSOAR API connection using a dedicated service account and least-privilege API key.

Instructions in Martini

  • Confirm the deployed Cortex XSOAR version, base URL, tenant routing, required headers, and endpoint behavior.
  • Store the API key and endpoint configuration in Martini Secrets Management and environment configuration.
  • Test authentication without exposing credentials in payloads or logs.

Objective

Select an event, API, or schedule that matches the availability and coverage of the Cortex XSOAR integration mechanism.

Instructions in Martini

  • Use a Martini API for inbound alerts or supported callback traffic.
  • Use a scheduled workflow for polling Incidents, Indicators, Jobs, or changed resources.
  • Treat webhook-style notifications as selected-event mechanisms rather than universal object events.

Objective

Receive or retrieve Cortex XSOAR data with bounded queries and version-aware request handling.

Instructions in Martini

  • Use server-side filters, time windows, pagination, and explicit limits.
  • Capture Incident IDs, Indicator values, Job identifiers, and source correlation keys.
  • Separate metadata, entries, files, and large evidence content when processing responses.

Objective

Coordinate calls, branching, asynchronous operations, and downstream writes in a maintainable Martini workflow.

Instructions in Martini

  • Separate validation, lookup, create, update, and notification stages.
  • Poll documented Job or execution status when an operation is asynchronous.
  • Use checkpoints and controlled concurrency for batch processing.

Objective

Convert Cortex XSOAR objects and source payloads into canonical and target-specific models.

Instructions in Martini

  • Map Incident status, severity, owner, source, custom fields, and identifiers explicitly.
  • Normalize Indicator formats while preserving original values where forensic traceability is required.
  • Apply data minimization before sending War Room or file content to another system.

Objective

Control deduplication, routing, state transitions, permissions, and target update behavior.

Instructions in Martini

  • Check stable source identifiers before creating Incidents.
  • Define authoritative fields and permitted status transitions for bidirectional synchronization.
  • Route authentication, validation, throttling, missing-object, and server failures differently.

Common Cortex XSOAR data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
IncidentsRepresent security cases created from alerts, integrations, feeds, or manual activity.ServiceNow, Jira, Splunk, Microsoft Sentinel, Slack, and Microsoft TeamsMartini validates and normalizes Incident payloads, maps status, severity, ownership, source, custom fields, and correlation identifiers, and applies create-versus-update logic.
IndicatorsStore observables such as IP addresses, domains, URLs, hashes, and other threat-intelligence objects.Threat-intelligence services, SIEM platforms, data stores, and downstream security toolsMartini normalizes indicator values, preserves original values for traceability, enriches them through approved APIs, and maps confidence, source, and timestamps.
InvestigationsProvide investigation context associated with Incidents and response activity.Reporting systems, ticketing platforms, SIEM platforms, and analyst toolsMartini retrieves supported investigation data, filters sensitive content, creates a controlled summary, and routes only the required fields to authorized targets.
PlaybooksDefine automation and orchestration logic used to investigate or respond to Incidents.Cortex XSOAR workflows, reporting systems, and response-status consumersMartini can invoke or monitor supported Playbook operations when exposed by the deployed API and permitted for the service account, while treating completion as potentially asynchronous.
War RoomsContain investigation activity, commands, results, analyst entries, and automation output.ServiceNow, Jira, collaboration tools, evidence repositories, and reporting systemsMartini retrieves selected entries or files, applies data-minimization and retention rules, and distributes controlled summaries rather than copying complete evidence packages by default.
JobsRepresent scheduled or asynchronous execution units used for background operations.Martini workflow state, monitoring systems, and operational dashboardsMartini stores the Job identifier, polls status when required, applies bounded retry and timeout policies, and records the final outcome with correlation data.

Authentication and security considerations

API-key authentication

Cortex XSOAR REST API access is generally authenticated with an API key in the Authorization header. The key inherits the permissions of its associated Cortex XSOAR user.

Least privilege and secret protection

  • Use a dedicated service account with only the roles required by the integration.
  • Store the API key in Martini Secrets Management rather than in workflow definitions or mappings.
  • Use HTTPS, validate the target tenant or server URL, and rotate keys according to policy.
  • Ensure error handling and logs do not expose authorization headers, evidence, or sensitive War Room content.

Version-aware security

Confirm tenant-specific headers, routing requirements, endpoint behavior, and permissions against the deployed Cortex XSOAR version. OAuth 2.0, JWT bearer authentication, and Basic Authentication should not be assumed for the XSOAR REST API unless separately documented for the deployment.

Operational considerations for Cortex XSOAR integrations

Version and schema differences

Cortex XSOAR API paths, request bodies, pagination behavior, bulk limits, Job responses, and file operations can vary by version. Validate the deployed version and keep mappings configurable for custom Incident fields, layouts, classifications, and integration outputs.

Pagination and rate control

Use server-side filters, time windows, explicit limits, and pagination for Incident and Indicator searches. Control concurrency and use exponential backoff for transient failures because effective capacity depends on the deployment, endpoint, and other analyst or automation activity.

Idempotency and asynchronous work

Use stable source alert IDs, Cortex XSOAR Incident IDs, or correlation keys to distinguish new Incidents, updates, duplicate deliveries, and replays. Treat accepted Job, Playbook, investigation, or bulk requests as potentially incomplete and poll the documented status mechanism.

Evidence and observability

  • Separate Incident metadata, War Room entries, file metadata, and file contents.
  • Apply content-type, size, retention, and malware-handling controls to evidence.
  • Record sanitized correlation IDs, Incident IDs, Job IDs, HTTP status codes, and processing outcomes.
  • Test authentication, pagination, retries, duplicate events, custom fields, and version-specific responses before production release.

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

Orchestration beyond point-to-point calls

Martini provides a reusable workflow layer for receiving alerts, calling Cortex XSOAR APIs, enriching Indicators, synchronizing Incidents, monitoring asynchronous Jobs, and distributing controlled response results. This avoids duplicating authentication, mapping, retry, and correlation logic across individual scripts.

Controlled APIs and transformations

Martini can expose a normalized API to internal applications while keeping Cortex XSOAR-specific credentials and request details inside reusable workflows. It can validate payloads, transform different alert schemas, apply state and routing rules, and limit sensitive investigation content before it reaches downstream systems.

Maintainability and operations

  • Centralize environment-specific URLs, API keys, and configuration.
  • Use explicit mappings for status, severity, ownership, custom fields, and identifiers.
  • Apply consistent retries, checkpoints, idempotency, and error classification.
  • Monitor workflow execution and troubleshoot version-dependent API behavior without embedding integration logic in every application.

Frequently asked questions

How can Cortex XSOAR be integrated with enterprise systems?

Cortex XSOAR can be integrated through its versioned REST APIs, API-key authentication, selected webhook-style ingestion and callback mechanisms, and supported bulk, asynchronous, entry, and file operations. Enterprise workflows can create and synchronize Incidents, process Indicators, monitor Jobs, retrieve investigation data, and distribute controlled response results.

Can Martini integrate with Cortex XSOAR?

Yes. Martini can consume Cortex XSOAR REST APIs, receive external alerts through a Martini API or selected webhook-style mechanisms, transform payloads, apply validation and business rules, and route Incidents, Indicators, investigation results, or response summaries to downstream systems.

Do I need a connector to integrate Cortex XSOAR with Martini?

No. A dedicated Cortex XSOAR connector is not required. Martini can use Cortex XSOAR's confirmed native REST APIs, API-key authentication, selected webhook-style HTTP mechanisms, and supported file or asynchronous operations through workflows and APIs.

Is there any extra Lonti cost to integrate Cortex XSOAR with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Cortex XSOAR. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Palo Alto Networks, cloud infrastructure, or other third-party systems based on licensing, usage, and deployment model.

Which Cortex XSOAR integration methods should an implementation use?

The REST API is the primary integration method for Incidents, Indicators, investigations, Jobs, Playbooks, entries, and other supported resources. Selected webhook-style mechanisms are useful for ingestion or callbacks, while bulk, asynchronous, and file operations should be used only where supported and verified for the deployed XSOAR version.

Does Cortex XSOAR provide webhooks or event notifications for changes?

Cortex XSOAR supports webhook-style integration patterns for selected integrations and use cases, but it should not be assumed that every Incident, Indicator, or Playbook change produces an outbound event. Where universal notifications are unavailable, Martini can use documented REST polling with bounded searches and checkpoints.

How does Martini synchronize Cortex XSOAR data and handle mapping?

Martini can run scheduled or event-driven workflows that retrieve or receive XSOAR data, map actual objects such as Incidents and Indicators to canonical models, and write selected fields to systems such as ServiceNow, Jira, Splunk, or collaboration platforms. Explicit mappings should define status, severity, ownership, identifiers, custom fields, and unsupported values.

How are errors, retries, duplicates, and asynchronous operations handled?

Martini can distinguish validation, authentication, throttling, missing-object, and server-side failures, then apply appropriate retry or escalation behavior. Stable source identifiers support idempotent Incident creation and updates. For asynchronous Jobs, Playbooks, or investigations, workflows can poll documented status mechanisms, use backoff and timeouts, and persist checkpoints.

Related Martini documentation

APIs

Events

Workflows

Security

Operations

Integrate Cortex XSOAR with Martini

Use Martini to connect Cortex XSOAR with security, service management, collaboration, and reporting systems through maintainable workflows, controlled APIs, secure configuration, and version-aware data synchronization.

EXPLORE MARTINI
BOOK A DEMO