.png)
Exabeam Integration Guide
Integrate Exabeam security operations data with enterprise systems through REST APIs, scheduled workflows, and validated product-specific notifications.
Exabeam integration options at a glance
Exabeam’s primary confirmed integration mechanism is its REST API, which can provide access to supported Alerts, Cases, Users, Assets, Sessions, Watchlists, and other security operations data. API-key-based authentication is documented, although the required header, tenant, region, permissions, and API version should be confirmed for each product. Product-specific outbound notifications may be available for selected events, but general webhook coverage is not confirmed. Martini can consume the REST API, expose REST endpoints, orchestrate scheduled polling, paginate through results, map security data, and deliver normalized records to downstream systems. Direct database access, SOAP, GraphQL, and broadly documented bulk APIs should not be assumed.
| Integration point | Supported by Exabeam? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve and filter Alerts, Cases, Users, Assets, Sessions, Watchlists, and other resources exposed by the selected Exabeam product API. Use the API for polling, detail retrieval, and supported updates. | Martini can consume Exabeam REST endpoints, handle authentication, paginate through responses, transform JSON, apply business rules, and expose normalized REST APIs to other systems. |
| Authentication | Yes | Authenticate API requests using credentials provisioned through the Exabeam environment, including API-key-based access. Header names, tenant identifiers, regions, and permissions vary by API and product version. | Martini can store API keys in Secrets Management and inject them into environment-specific API configurations without placing credentials in mappings, source definitions, or logs. |
| Webhooks / outbound callbacks | Limited | Product-specific outbound integrations or notifications may be available for selected alert or case events, but general-purpose webhook coverage and delivery behavior were not confirmed. | Martini can receive a supported Exabeam HTTP notification through a workflow trigger after event coverage, authentication, retries, and ordering are validated. Scheduled polling remains the fallback. |
| Scheduled synchronization | Yes | Poll Exabeam REST endpoints for newly created or changed Alerts, Cases, and other supported objects when real-time notification coverage is unavailable or incomplete. | Martini can schedule workflows, maintain durable watermarks, use overlap windows, paginate results, deduplicate by stable IDs, and update checkpoints only after successful processing. |
| Pagination and filtering | Yes | Use the pagination, filtering, time-window, cursor, or offset behavior documented for the selected Exabeam API to process result sets without assuming a bulk endpoint. | Martini workflows can loop through pages, preserve cursors or offsets, apply incremental filters, and route incomplete or invalid responses to error handling paths. |
| Bulk / asynchronous / batch APIs | Not confirmed | A broadly documented Exabeam bulk or asynchronous REST API was not confirmed. Large-volume operations should use documented pagination, filtering, and time windows. | Martini can implement controlled paging and batching at the workflow level where the API permits it, without assuming a provider bulk operation. |
| File / attachment APIs | Not confirmed | Exabeam supports security data ingestion through product integrations, but a general-purpose public API for arbitrary case files or attachments was not confirmed. | Martini can handle files when Exabeam or another participating endpoint documents a supported file operation, but the specific attachment contract must be validated first. |
| GraphQL APIs | Not confirmed | No official Exabeam GraphQL API was confirmed in the reviewed documentation. | Martini should use the confirmed Exabeam REST APIs rather than assuming GraphQL support. |
| SOAP APIs | No | No official Exabeam SOAP API was identified in the supplied research. | Martini should not design the Exabeam integration around SOAP unless Exabeam provides separate product-specific documentation confirming it. |
How Exabeam exposes data and business events
Exabeam REST APIs
REST is Exabeam’s primary confirmed integration mechanism. Depending on the product and API version, REST endpoints can expose Alerts, Cases, Users, Assets, Sessions, Watchlists, investigation data, filtering, and supported updates. Endpoint availability and field coverage must be confirmed for the tenant.
Martini implementation pattern
Martini implementation pattern: Martini authenticates with an Exabeam API credential stored in Secrets Management, calls the relevant endpoint, handles pagination and response validation, maps the returned JSON to a canonical model, applies business rules, and writes or publishes the result to downstream systems.
Implementation sequence
Scheduled Exabeam synchronization
Scheduled polling is the recommended fallback when general-purpose webhook coverage is unavailable or when the required object type does not provide a validated notification. It is suitable for incremental Alert, Case, User, Asset, Session, or Watchlist synchronization.
Martini implementation pattern
Martini implementation pattern: A scheduler starts a workflow that reads the last successful watermark, queries Exabeam using time-window or cursor filters, processes each page, deduplicates by object ID, writes successful results, and advances the checkpoint only after completion.
Implementation sequence
Exabeam outbound notifications
Exabeam may provide product-specific outbound integrations or notifications for selected events, but public research did not confirm general webhook coverage for all Alerts, Cases, Sessions, Assets, or other objects. Event availability must be verified for the deployed product and tenant.
Martini implementation pattern
Martini implementation pattern: When a supported Exabeam notification exists, Martini exposes or consumes the required HTTP endpoint, authenticates the inbound request, validates the event, retrieves the current Exabeam resource if necessary, and sends the normalized result through a workflow. Polling covers unsupported or missed event types.
Implementation sequence
Common Exabeam integration patterns
Pattern 1: Synchronize Exabeam alerts with ServiceNow
When to use this pattern
Use this pattern when Exabeam remains the detection platform and ServiceNow owns enterprise incident assignment, approvals, reporting, or remediation tracking. A scheduled workflow is appropriate unless the required Exabeam event notification is confirmed.
Integration direction
Example Mapping
| Exabeam Field | Canonical Field | Target Field |
|---|---|---|
| alert.id | sourceAlertId | u_exabeam_alert_id |
| severity | severity | priority |
| detectionName | detectionName | short_description |
| affectedUsers | affectedUsers | description |
Martini implementation pattern
Martini retrieves new or changed Alerts, enriches them with Users and Assets, maps Exabeam severity to an explicit ServiceNow priority table, and creates or updates incidents using the Exabeam Alert ID as an idempotency key. Transient API failures are retried with backoff; validation, permission, and mapping failures are routed for operational review.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Synchronize Exabeam cases with ServiceNow
When to use this pattern
Use this pattern when Exabeam is the investigation system but ServiceNow provides enterprise ownership and lifecycle reporting. The supported Case fields and update operations should be confirmed for the deployed Exabeam API version.
Integration direction
Example Mapping
| Exabeam Field | Canonical Field | Target Field |
|---|---|---|
| case.id | sourceCaseId | u_exabeam_case_id |
| status | caseStatus | state |
| priority | casePriority | priority |
| resolution | resolutionSummary | close_notes |
Martini implementation pattern
A Martini workflow polls Cases using a durable watermark, maps case status and priority through controlled tables, and synchronizes analyst or resolution information where both APIs permit it. The workflow stores the ServiceNow identifier beside the Exabeam Case ID and prevents duplicate incidents during overlapping polling windows.
Martini capabilities used
- workflows
- API consumption
- incremental synchronization
- data mapping
- idempotency
- retry handling
Pattern 3: Enrich Exabeam investigations with identity and endpoint context
When to use this pattern
Use this pattern when an Exabeam Alert or Case requires additional user, group, host, endpoint, or response context from Okta, CrowdStrike Falcon, or Microsoft Defender XDR. Exact object and action coverage depends on the participating APIs.
Integration direction
Example Mapping
| Exabeam Field | Canonical Field | Target Field |
|---|---|---|
| asset.hostname | assetHostname | device.hostname |
| user.id | userIdentifier | account.id |
| alert.id | sourceAlertId | relatedDetectionId |
| risk | riskScore | riskScore |
Martini implementation pattern
Martini receives or retrieves an Exabeam Alert, extracts user and asset identifiers, calls the selected identity or endpoint API, normalizes the returned context, and writes enrichment to a case or exposes it through a controlled API. Missing enrichment is handled as a distinct outcome, while rate limits and transient failures use bounded retries.
Martini capabilities used
- workflow orchestration
- API consumption
- data mapping
- conditional routing
- business rules
- error handling
Pattern 4: Export Exabeam security data for reporting
When to use this pattern
Use this pattern when security teams need periodic Alert, Case, or investigation extracts in a reporting platform, data store, flat file, or controlled internal API. It is designed for APIs that provide pagination and time-window or filtering support rather than an assumed bulk endpoint.
Integration direction
Example Mapping
| Exabeam Field | Canonical Field | Target Field |
|---|---|---|
| id | exabeamObjectId | source_object_id |
| createdAt | createdAtUtc | created_at |
| updatedAt | updatedAtUtc | updated_at |
| status | lifecycleStatus | status |
Martini implementation pattern
A scheduled Martini workflow retrieves pages of Exabeam data, normalizes timestamps to UTC, preserves source identifiers and selected original fields, and writes JSON or another approved representation to the reporting target. It records the watermark only after successful delivery and isolates malformed objects for later replay.
Martini capabilities used
- scheduling
- API consumption
- pagination
- data transformation
- file or API delivery
- monitoring
Applications commonly integrated with Exabeam
Exabeam can be integrated with security, identity, endpoint, service-management, and reporting applications through their supported APIs and ingestion mechanisms. The exact direction and object coverage should be validated for the deployed products and tenant configuration.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create and update incidents or security cases from Exabeam Alerts and Cases while synchronizing ownership, status, and resolution information where both APIs permit it. | Exabeam → Martini → ServiceNow | A scheduled workflow or validated Exabeam notification retrieves Alerts or Cases, enriches them with Users and Assets, applies severity and status mappings, and creates or updates ServiceNow incidents using an Exabeam-to-ServiceNow identifier map. |
| Splunk | Exchange selected security events, investigation context, detections, or historical data in environments operating both platforms during migration or hybrid SOC operations. | Splunk → Martini → Exabeam | Martini consumes supported Splunk and Exabeam APIs, normalizes event and detection fields, applies filtering and deduplication rules, and routes only approved security data between the platforms. |
| Microsoft Sentinel | Coordinate security analytics data, incidents, and investigation context where Microsoft security tooling operates alongside Exabeam. | Microsoft Sentinel → Martini → Exabeam | Martini polls or receives supported data from Microsoft Sentinel, maps incidents and detections to Exabeam-compatible structures, and uses Exabeam REST endpoints where the deployed API exposes the required operations. |
| CrowdStrike Falcon | Enrich Exabeam Alerts and Cases with endpoint, host, detection, and response information, or coordinate endpoint actions where permissions and APIs support them. | Exabeam → Martini → CrowdStrike Falcon | A Martini workflow retrieves an Exabeam Alert or Case, calls CrowdStrike Falcon for endpoint context, applies response and authorization rules, and writes enrichment to the target case or exposes it through a normalized API. |
| Microsoft Defender XDR | Add endpoint, identity, email, and incident context to Exabeam investigations in Microsoft security environments. | Microsoft Defender XDR → Martini → Exabeam | Martini orchestrates calls to both platforms, correlates stable alert, incident, user, and asset identifiers, transforms nested security payloads, and records failures without losing the original evidence context. |
| Okta | Enrich detections with users, groups, authentication activity, and sign-in information, or correlate identity events with Exabeam Alerts and Cases. | Okta → Martini → Exabeam | Martini retrieves identity and authentication context from Okta, maps it to Exabeam Users or security data where supported, and applies privacy, filtering, and retry policies before delivery. |
| Palo Alto Networks Cortex XDR | Correlate endpoint detections and response information with Exabeam Alerts and Cases in a broader security operations workflow. | Palo Alto Networks Cortex XDR → Martini → Exabeam | Martini consumes supported APIs from both products, correlates host and detection identifiers, enriches investigation data, and routes permanent authorization or mapping failures for review. |
| Jira | Create development, infrastructure, or remediation work items from selected Exabeam Cases and security investigations. | Exabeam → Martini → Jira | A Martini workflow filters eligible Cases, maps severity and remediation details to Jira fields, creates or updates issues idempotently, and preserves the source Exabeam identifier for later reconciliation. |
How to build a Exabeam integration in Martini
Objective
Establish the Exabeam API configuration for the target product, tenant, region, and version while keeping credentials environment-specific.
Instructions in Martini
- Confirm the Exabeam API host, tenant requirements, header format, and permission scope
- Store the API key in Martini Secrets Management
- Configure separate credentials for development, testing, and production
- Avoid writing credentials or sensitive payloads to workflow logs
Objective
Select the integration trigger based on confirmed Exabeam event coverage and the required synchronization latency.
Instructions in Martini
- Use a validated Exabeam outbound notification only for confirmed event types
- Use a Scheduler Trigger for polling when webhook coverage is unavailable or incomplete
- Define the polling interval, overlap window, and concurrency limits
- Document the selected API version and object coverage
Objective
Retrieve the current Exabeam resource or event data using supported REST endpoints and provider-specific query behavior.
Instructions in Martini
- Request Alerts, Cases, Users, Assets, Sessions, or Watchlists through documented endpoints
- Apply server-side filters and time windows where available
- Follow returned page tokens, cursors, or offsets
- Preserve stable Exabeam object identifiers and source timestamps
Objective
Coordinate retrieval, enrichment, validation, transformation, delivery, and checkpointing as a maintainable Martini workflow.
Instructions in Martini
- Separate authentication, retrieval, mapping, business rules, and delivery into clear workflow stages
- Call identity, endpoint, incident, or reporting APIs only when the object requires enrichment
- Use conditional routing for create, update, ignore, and failure outcomes
- Keep the original Exabeam context available for audit and troubleshooting
Objective
Convert Exabeam security objects into canonical and target-specific models without losing important forensic context.
Instructions in Martini
- Map severity, risk, status, timestamps, users, assets, and detection names explicitly
- Normalize timestamps to UTC and preserve source values where required
- Retain source identifiers for correlation and deduplication
- Use tolerant JSON handling for nested or newly added fields
Objective
Apply operational, privacy, authorization, and idempotency rules before writing to downstream systems.
Instructions in Martini
- Use Exabeam Alert or Case IDs as stable idempotency keys
- Define explicit severity and status mappings for each target
- Filter sensitive fields and limit diagnostic logging
- Distinguish first-time creation from updates and unchanged objects
Common Exabeam data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Alerts | Route detection outputs to incident management, enrichment, investigation, or reporting workflows. | ServiceNow, Microsoft Sentinel, Splunk, Jira, data warehouses | Martini retrieves filtered Alerts, preserves stable identifiers and original severity, enriches them with Users and Assets, maps fields, and deduplicates downstream writes. |
| Cases | Synchronize investigation or incident containers, including status, priority, analyst ownership, evidence references, and resolution information where supported. | ServiceNow, Jira, Microsoft Sentinel, reporting platforms | Martini polls or receives supported notifications, maps case states explicitly, maintains source-to-target identifiers, and routes unsupported update operations for review. |
| Users | Provide identity context for detections, investigations, authentication activity, and user-risk analysis. | Okta, Microsoft Entra ID, ServiceNow, security analytics platforms | Martini retrieves Users when needed for enrichment, minimizes sensitive fields, normalizes identifiers, and applies data-access and logging rules. |
| Assets | Represent devices, hosts, servers, applications, and other infrastructure associated with security activity. | CrowdStrike Falcon, Microsoft Defender XDR, ServiceNow, CMDBs | Martini correlates asset identifiers, enriches Alerts or Cases with endpoint context, and applies explicit matching rules for hostnames, addresses, and platform identifiers. |
| Sessions | Represent aggregated user or entity activity used for investigation and behavioral analysis. | Security analytics platforms, reporting stores, internal investigation APIs | Martini retrieves supported session data in controlled windows, transforms nested activity structures, preserves timestamps in UTC, and delivers only required fields. |
| Watchlists | Maintain lists of users, assets, indicators, or entities used in monitoring and detection logic. | Security operations platforms, identity systems, governance stores | Martini can synchronize supported Watchlists through documented endpoints, apply membership and authorization rules, and record source identifiers for reconciliation. |
Authentication and security considerations
API-key authentication
Exabeam REST APIs use credentials provisioned through the Exabeam environment, including API-key-based access. The required authorization or API-key header, tenant identifier, region, and permission scope can vary by API family and product version.
Credential protection
- Store Exabeam API keys in Martini Secrets Management.
- Use dedicated service credentials with the minimum required permissions.
- Separate development, test, and production credentials.
- Do not place credentials in mappings, workflow source, or diagnostic logs.
Security data controls
Alerts, Cases, usernames, hostnames, IP addresses, and investigation notes may be sensitive. Restrict workflow access, minimize logged payloads, and protect data in transit and at rest according to the deployment requirements.
Operational considerations for Exabeam integrations
Rate limits and pagination
Confirm tenant-specific quotas and the pagination contract for each Exabeam API. Use controlled concurrency, server-side filters, time windows, and bounded retries with backoff.
Incremental synchronization
Maintain a durable watermark based on updatedAt, a cursor, or an object identifier. Use a small overlap window for eventual consistency and deduplicate by stable Exabeam IDs.
Idempotency and mapping
Store mappings between Exabeam Alert or Case identifiers and target identifiers. Translate severity, risk, and status through explicit tables and retain original values for auditability.
Schema and timestamp changes
Use tolerant JSON handling for new or nested security fields, isolate mappings by API version, normalize timestamps to UTC, and preserve source timestamps when forensic traceability matters.
Testing and recovery
Test authentication, permissions, pagination, rate limiting, duplicate delivery, missing objects, malformed payloads, and downstream outages. Retry only safe transient failures and route permanent failures for operational review.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than an API call
Exabeam integrations commonly require pagination, incremental watermarks, enrichment from identity or endpoint systems, explicit severity mapping, idempotency, and controlled delivery. Martini keeps these concerns in an observable workflow instead of scattering them across scripts.
Reusable integration assets
Martini can expose normalized REST APIs, reuse authentication and transformation logic, and separate environment-specific configuration from workflow behavior. This supports repeatable integrations across Exabeam products and downstream systems.
Operational reliability
- Use scheduled, event-driven, or API-led workflows according to confirmed Exabeam capabilities.
- Apply validation, conditional routing, retries, and error handling consistently.
- Monitor processing outcomes without exposing sensitive security payloads.
- Adapt mappings as Exabeam API versions and security schemas evolve.
Frequently asked questions
Exabeam can be integrated primarily through its REST APIs, using API-key-based authentication to retrieve supported Alerts, Cases, Users, Assets, Sessions, Watchlists, and other product data. Scheduled polling is appropriate when required events do not have validated outbound notifications. Product-specific notifications may support selected real-time scenarios, but general webhook coverage should be confirmed for the tenant and object type.
Yes. Martini can consume Exabeam REST APIs, authenticate with securely stored API credentials, paginate through results, map and transform security data, orchestrate enrichment calls, and deliver results to systems such as ServiceNow. Martini can also receive supported Exabeam outbound notifications when the relevant product and event type provide them.
No dedicated Exabeam connector is required. Martini can integrate using Exabeam’s confirmed native REST APIs and authentication methods, with scheduled workflows or validated outbound notifications for event-driven processing.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Exabeam. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Exabeam, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
REST APIs are the primary confirmed method for new Exabeam integrations. Use documented filtering, pagination, and time-window capabilities for synchronization. Product-specific outbound notifications can be considered only after confirming event coverage, authentication, retries, and ordering. GraphQL and SOAP were not confirmed and should not be assumed.
Only where the relevant Exabeam product exposes a supported outbound notification for the required event. General webhook coverage for all Alerts, Cases, Sessions, and Assets was not verified. If the necessary event is unavailable, Martini can use scheduled REST polling with an overlap window and stable-ID deduplication.
A Martini workflow can maintain a durable timestamp, cursor, or identifier watermark, retrieve pages of changed Exabeam objects, and map them into canonical and target-specific models. Explicit rules should translate severity and status, while source IDs and timestamps are retained for auditability and idempotent updates.
Martini can distinguish authentication, authorization, validation, rate-limit, missing-object, and transient server errors. Safe transient failures can be retried with bounded backoff, while permanent failures are routed for review. Stable Exabeam Alert and Case identifiers, paired with target-ID mappings, prevent duplicate downstream objects.
Related Martini documentation
Workflows
Integrate Exabeam with Martini
Use Martini to connect Exabeam REST APIs and validated notifications with service-management, identity, endpoint, and reporting systems through secure, maintainable workflows.