.png)
Abnormal Security Integration Guide
Connect Abnormal Security REST APIs with enterprise security, ITSM, identity, analytics, and reporting systems using OAuth 2.0 and Martini workflows.
Abnormal Security integration options at a glance
Abnormal Security primarily integrates through REST APIs authenticated with OAuth 2.0. Martini can obtain and refresh access tokens, retrieve paginated Threats, Messages, Cases, Attackers, Users, and Audit logs, and invoke supported investigation or response operations. Collection retrieval and pagination support scheduled incremental synchronization, while a separate bulk export or asynchronous batch API has not been confirmed. General-purpose webhooks and outbound callbacks are also not confirmed across the platform, so event coverage should be validated for the specific product and event. Martini can transform Abnormal Security JSON, apply business rules, checkpoint progress, and deliver results to security, ITSM, identity, analytics, and reporting systems.
| Integration point | Supported by Abnormal Security? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve Threats, Messages, Cases, Attackers, Users, and Audit logs, and invoke supported investigation or response operations. | Martini can consume the Abnormal Security REST API from workflows, handle JSON responses and pagination, apply transformations, and expose controlled APIs backed by Abnormal Security data. |
| Authentication | Yes | OAuth 2.0 client credentials are used to obtain bearer tokens for API requests. Scopes and permissions may vary by tenant and API product. | Martini can store client credentials and token configuration in secrets or environment configuration, obtain tokens, refresh them as required, and keep credentials out of workflow logic. |
| Scheduled synchronization | Yes | Scheduled polling is a practical approach for incremental retrieval when general-purpose webhook coverage is not confirmed. | Martini scheduler-triggered workflows can retrieve changed collections, process pages, persist checkpoints, and apply bounded retries and rate-limit handling. |
| Bulk / asynchronous APIs | Limited | Collection-style retrieval and pagination support larger synchronizations, but a separate bulk export or asynchronous batch API was not confirmed. | Martini can paginate through collection responses, use time-window filters where available, checkpoint progress, and make downstream writes idempotent. |
| Webhooks / outbound callbacks | Not confirmed | General-purpose coverage for Threats, Cases, Messages, and other events was not established. Product- and event-specific support must be validated. | If a required callback is confirmed, Martini can receive it through a webhook-triggered workflow. Otherwise, Martini can use scheduled REST polling as the documented fallback. |
| File / attachment APIs | Not confirmed | Email and threat-related content may include attachment information, but a general-purpose attachment retrieval API was not confirmed. | Martini can process file data when a documented endpoint is available, but attachment retrieval and forwarding should remain endpoint-specific until validated. |
| Database / analytics access | No | Direct customer database or SQL access was not confirmed. Reporting or metrics endpoints, if available, should not be treated as a general database interface. | Martini should consume the documented APIs and can write normalized results to an approved database or reporting destination. |
| GraphQL APIs | Not confirmed | No official Abnormal Security GraphQL API was confirmed in the reviewed documentation. | Martini can consume GraphQL APIs generally, but an Abnormal Security REST integration should be used unless a tenant- or product-specific GraphQL interface is verified. |
How Abnormal Security exposes data and business events
Abnormal Security REST APIs
Abnormal Security provides REST APIs for platform data and operations, including access to Threats, Messages, Cases, Attackers, Users, and Audit logs. Available fields and operations depend on the enabled API products and tenant permissions.
Martini implementation pattern
Martini implementation pattern: a workflow obtains an OAuth 2.0 bearer token, calls the relevant collection or detail endpoints, handles pagination, maps the JSON response into a canonical model, applies business rules, and writes to downstream systems or exposes a controlled internal API.
Implementation sequence
Scheduled REST synchronization
Because general-purpose webhook coverage was not confirmed, scheduled polling is the safer documented pattern for incremental synchronization. A workflow can retrieve changed collections using supported time-window, timestamp, cursor, or identifier filters.
Martini implementation pattern
Martini implementation pattern: a scheduler starts the workflow, the workflow loads its last successful checkpoint, retrieves paginated results with an overlap where necessary, processes each object idempotently, and advances the checkpoint only after successful downstream writes.
Implementation sequence
OAuth 2.0 authentication
Abnormal Security API access uses OAuth 2.0 credentials issued through the Abnormal Security platform. The client credentials are exchanged for an access token that is sent as a bearer token with API requests.
Martini implementation pattern
Martini implementation pattern: credentials, token configuration, scopes, and permissions are stored in secure environment configuration; the workflow obtains or refreshes a token before API calls and handles authentication failures separately from business-level errors.
Implementation sequence
Webhook-style notifications
The reviewed public information does not establish a general-purpose webhook covering all Abnormal Security events. Any tenant- or product-specific notification must be validated for the required event type before adoption.
Martini implementation pattern
Martini implementation pattern: if Abnormal Security confirms a callback for a required event, Martini can expose a controlled webhook endpoint, validate the request, retrieve authoritative resource details, and process the event idempotently. Without confirmed callbacks, use scheduled REST polling.
Implementation sequence
Common Abnormal Security integration patterns
Pattern 1: Create ServiceNow incidents from Threats and Cases
When to use this pattern
Use this pattern when security operations teams need Abnormal Security detections represented as actionable incidents. A scheduled workflow retrieves newly changed Threats and Cases, maps severity, sender, recipient, detection reason, and investigation information, and creates or updates ServiceNow records without duplication.
Integration direction
Example Mapping
| Abnormal Security Field | Canonical Field | Target Field |
|---|---|---|
| Threat ID | sourceThreatId | u_abnormal_threat_id |
| Severity | severity | priority |
| Detection reason | detectionReason | description |
| Case status | caseStatus | state |
Martini implementation pattern
Martini obtains an OAuth token, polls changed collections, follows pagination, normalizes Threat and Case payloads, and applies severity-based routing. The workflow uses the stable Threat ID or Case ID as an idempotency key, updates existing incidents on replay, and retries transient target or vendor failures without losing the checkpoint.
Martini capabilities used
- workflows
- API consumption
- OAuth 2.0 configuration
- data mapping
- business rules
- idempotent writes
- error handling
Pattern 2: Send security activity to Splunk or Microsoft Sentinel
When to use this pattern
Use this pattern to centralize Abnormal Security Threats, Cases, and Audit logs with endpoint, identity, and cloud-security telemetry. Incremental retrieval and normalized event schemas reduce repeated full exports and support correlation across security tools.
Integration direction
Example Mapping
| Abnormal Security Field | Canonical Field | Target Field |
|---|---|---|
| Threat ID | eventId | source.event_id |
| Attacker identity | actor | source.attacker |
| Audit event time | eventTime | event.time |
| Case status | status | security_case.status |
Martini implementation pattern
A scheduler-triggered Martini workflow loads a checkpoint, retrieves paginated data for an incremental time window, transforms Abnormal Security JSON into the selected SIEM schema, and submits events through the target API. The workflow uses bounded retries, respects rate-limit responses, and preserves source identifiers for replay detection.
Martini capabilities used
- scheduled workflows
- API consumption
- JSON handling
- data transformation
- checkpointing
- rate-limit-aware retries
- monitoring
Pattern 3: Correlate threats with Microsoft 365 and identity context
When to use this pattern
Use this pattern when analysts need mailbox, message, or user context alongside an Abnormal Security investigation. The workflow can enrich a Threat or Case, apply an approval or business rule, and invoke only the response operations confirmed in the relevant vendor APIs.
Integration direction
Example Mapping
| Abnormal Security Field | Canonical Field | Target Field |
|---|---|---|
| User ID | userIdentifier | Microsoft 365 or Okta user ID |
| Message sender | senderAddress | mail message sender |
| Threat ID | investigationReference | case correlation ID |
| Case status | responseStatus | workflow response status |
Martini implementation pattern
Martini retrieves the Abnormal Security Threat or Case, queries the permitted Microsoft 365 or Okta endpoints, normalizes user and message identifiers, and evaluates approval and response rules. It records the outcome against the source Case or downstream work item and treats unsupported remediation operations as validation exceptions rather than assuming they exist.
Martini capabilities used
- workflow orchestration
- API consumption
- data enrichment
- mapping and transformation
- business rules
- approval routing
- error handling
Pattern 4: Synchronize security data to a reporting database
When to use this pattern
Use this pattern for historical retention, trend analysis, case-status reporting, and cross-system audit reporting. Threats, Cases, Attackers, and Audit logs can be normalized into relational tables or a reporting model using scheduled incremental retrieval.
Integration direction
Example Mapping
| Abnormal Security Field | Canonical Field | Target Field |
|---|---|---|
| Threat ID | threatId | abnormal_threat_id |
| Case ID | caseId | abnormal_case_id |
| Attacker identity | attackerIdentity | attacker_identity |
| Audit event time | activityTimestamp | activity_timestamp |
Martini implementation pattern
A Martini workflow reads paginated API responses, validates optional fields, maps objects to database tables, and uses source identifiers as keys for upserts. It commits progress only after successful writes, keeps an overlap in time-window queries where necessary, and routes malformed payloads or database outages to controlled error handling.
Martini capabilities used
- scheduled synchronization
- API consumption
- data mapping
- database connectivity
- validation
- upserts
- checkpointing
- error handling
Applications commonly integrated with Abnormal Security
Abnormal Security data can be orchestrated with adjacent email, identity, security operations, analytics, and service-management applications. The exact operations available depend on the Abnormal Security APIs, tenant permissions, and the capabilities of the target system.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Microsoft 365 | Combine Abnormal Security detections with Exchange Online mailbox and message context and coordinate supported email-response actions. | Microsoft 365 → Martini → Abnormal Security | Martini retrieves or receives the relevant security context, queries Microsoft 365 for mailbox or message information, applies approval and response rules, and updates the appropriate case or downstream record. Remediation operations must be confirmed in both platforms. |
| Google Workspace | Correlate Abnormal Security detections with Gmail and Google Workspace user or message data. | Google Workspace → Martini → Abnormal Security | A Martini workflow combines Abnormal Security API responses with Google Workspace context, normalizes user and message identifiers, applies investigation rules, and writes results to the selected security or case-management destination. |
| ServiceNow | Create and update incidents or security cases from Abnormal Security Threats and Cases. | Abnormal Security → Martini → ServiceNow | A scheduled Martini workflow retrieves changed Threats and Cases, maps severity and investigation fields, uses stable source identifiers for idempotency, and creates or updates ServiceNow incidents. Status changes can be routed back when supported by the relevant APIs. |
| Splunk | Send threat, case, and audit information to a centralized security analytics environment for correlation and retention. | Abnormal Security → Martini → Splunk | Martini polls incremental Abnormal Security collections, transforms the JSON into the target event model, enriches records where required, and submits them to Splunk while checkpointing the latest successfully processed timestamp or identifier. |
| Microsoft Sentinel | Correlate Abnormal Security activity with identity, endpoint, and cloud-security telemetry. | Abnormal Security → Martini → Microsoft Sentinel | Martini retrieves Threats, Cases, and Audit logs, applies field and severity normalization, and sends the resulting events to Microsoft Sentinel through its supported ingestion interface. Bounded retries and duplicate detection protect replayed pages. |
| Okta | Enrich investigations with identity and user context or coordinate account-related response procedures. | Abnormal Security → Martini → Okta | A Martini workflow correlates Abnormal Security Users or threat indicators with Okta identities, applies least-privilege response rules, and records the outcome in the relevant case or audit destination. Exact response actions require API validation. |
| CrowdStrike Falcon | Correlate email threats with endpoint or identity investigations across the security operations environment. | Abnormal Security → Martini → CrowdStrike Falcon | Martini normalizes identifiers and indicators from Abnormal Security and CrowdStrike Falcon, applies correlation rules, and routes enriched investigation data to the selected case or analytics system. The flow does not assume a direct native dependency between the vendors. |
| Jira Service Management | Create investigation or remediation work items for security and IT teams. | Abnormal Security → Martini → Jira Service Management | Martini maps Abnormal Security Threat and Case attributes into Jira Service Management request or issue fields, stores the source identifier for idempotency, and synchronizes selected status information when the target API supports it. |
How to build a Abnormal Security integration in Martini
Objective
Configure the Abnormal Security API access model and protect tenant-specific credentials before building the workflow.
Instructions in Martini
- Store the OAuth client ID, client secret, token configuration, and required scopes in Martini secrets or environment configuration.
- Use separate credentials and permissions for development, testing, and production where possible.
- Confirm the API product, tenant permissions, and supported operations required by the integration.
Objective
Select a trigger based on the confirmed Abnormal Security event model and synchronization requirements.
Instructions in Martini
- Use a scheduler trigger for incremental REST polling when event callbacks are not confirmed.
- Use a webhook-triggered workflow only after validating support for the specific Abnormal Security product and event.
- Define the polling interval or callback security requirements according to the operational use case.
Objective
Retrieve authoritative Abnormal Security objects without assuming that one response contains a complete collection.
Instructions in Martini
- Obtain an OAuth 2.0 access token before calling the API.
- Call the required Threat, Message, Case, Attacker, User, or Audit log endpoints.
- Follow pagination and use supported time-window, cursor, or updated-after filters.
- Persist a checkpoint only after the corresponding page has been processed successfully.
Objective
Coordinate retrieval, enrichment, validation, routing, target writes, and exception handling in a maintainable Martini workflow.
Instructions in Martini
- Separate token acquisition, API retrieval, transformation, target delivery, and error handling into understandable workflow stages.
- Use stable vendor identifiers and synchronization timestamps throughout the flow.
- Apply separate handling for authentication failures, rate limits, validation errors, and downstream outages.
Objective
Convert Abnormal Security JSON into the canonical and target-specific formats required by downstream systems.
Instructions in Martini
- Map source identifiers, severity, statuses, users, attackers, message context, and timestamps explicitly.
- Treat investigation, message, and attacker fields as potentially optional.
- Preserve source identifiers and selected original fields needed for traceability.
- Avoid writing full sensitive message content to logs unless explicitly required and protected.
Objective
Control routing, enrichment, response eligibility, and synchronization behavior according to security-operational requirements.
Instructions in Martini
- Route high-severity Threats to an appropriate response path or shorter polling interval when required.
- Apply approval and permission checks before invoking response operations in other systems.
- Use validation and idempotency rules to prevent duplicate incidents, cases, or events.
Common Abnormal Security data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Threats | Represent suspicious or malicious email threats detected by Abnormal Security and provide the basis for triage, monitoring, or response. | ServiceNow, Splunk, Microsoft Sentinel, Microsoft 365, relational databases | Martini retrieves Threats through REST endpoints, maps severity and identifiers, applies routing rules, and performs idempotent writes using a stable Threat ID. |
| Messages | Provide email messages associated with threats, investigations, or detection results. | Microsoft 365, Google Workspace, SIEM platforms, case-management systems | Martini retrieves supported message fields, minimizes sensitive content in logs, normalizes sender and recipient data, and forwards only the fields required by the target workflow. |
| Cases | Group investigation or response activity and track security-operational status. | ServiceNow, Jira Service Management, Microsoft Sentinel, reporting databases | Martini synchronizes Cases using stable Case IDs and update timestamps, maps status and investigation data, and prevents duplicate downstream cases during retries. |
| Attackers | Describe sender or attacker identities associated with detected threats. | SIEM platforms, threat-intelligence stores, security data warehouses | Martini normalizes attacker identifiers, domains, and related indicators, then enriches or correlates them with downstream security data where permitted. |
| Users | Represent mailbox users and security-platform users relevant to investigations and remediation. | Microsoft 365, Google Workspace, Okta, ITSM systems | Martini maps user identifiers and mailbox context, applies privacy and access rules, and correlates users with Threats or Cases without assuming every optional field is present. |
| Audit logs | Capture administrative or operational activity for compliance, monitoring, and security operations. | Splunk, Microsoft Sentinel, relational databases, reporting platforms | Martini retrieves audit data incrementally, transforms it into the target event model, preserves source identifiers, and checkpoints processed time ranges. |
Authentication and security considerations
OAuth 2.0 credentials
Abnormal Security API access uses OAuth 2.0 credentials issued through the platform. Martini can obtain bearer tokens and refresh or reacquire them as required by the token lifecycle.
Secrets and permissions
Store client IDs, client secrets, token configuration, and scopes in Martini secrets or environment configuration. Use least-privilege permissions and separate credentials for development, testing, and production where possible.
Sensitive security data
Threat and message data may contain confidential email content, personal information, indicators, or investigation details. Use TLS, restrict access, protect secrets, and avoid placing full message content or credentials in workflow logs.
Operational considerations for Abnormal Security integrations
Pagination and checkpoints
Threat, Case, Message, and Audit log collections may be paginated. Workflows should continue through all pages and persist a checkpoint only after successful processing.
Rate limits and retries
Confirm tenant quotas and rate limits. Use bounded exponential backoff for transient failures and HTTP 429 responses, respect any Retry-After guidance, and distinguish authentication, validation, and service failures.
Idempotency
Use stable Threat, Case, Message, or Audit Log IDs when writing to downstream systems. Overlapping time windows can reduce missed records, but they require duplicate-safe writes.
Schema and testing
Map vendor payloads through a controlled transformation layer, treat optional fields defensively, preserve source identifiers, and retest mappings when API versions or tenant product configurations change.
Event coverage
Do not assume that every threat, case, message, or remediation change produces a callback. Validate event-specific support and use scheduled polling when a required notification is unavailable.
Why use Martini instead of scripts or point-to-point integrations?
Reusable orchestration
Martini separates authentication, API retrieval, transformation, business rules, target delivery, and error handling into maintainable workflows rather than isolated scripts.
Reliable synchronization
Pagination, checkpoints, idempotent writes, bounded retries, and rate-limit handling provide a controlled approach to synchronizing security data at enterprise scale.
Controlled access
Martini can keep Abnormal Security credentials in secure configuration and expose a governed API façade for other applications, reducing direct dependency on vendor-specific access details.
Adaptable data movement
Mappings and transformations can route Abnormal Security data to ITSM, SIEM, identity, email, databases, and reporting systems while preserving source identifiers and traceability.
Frequently asked questions
Abnormal Security primarily integrates through REST APIs authenticated with OAuth 2.0. Enterprise workflows can retrieve Threats, Messages, Cases, Attackers, Users, and Audit logs, process paginated responses, and invoke supported investigation or response operations. General-purpose webhooks are not confirmed across the platform, so scheduled incremental polling may be required.
Yes. Martini can integrate with Abnormal Security by consuming its REST APIs with OAuth 2.0, handling pagination and token lifecycle, transforming JSON data, and orchestrating delivery to systems such as ServiceNow, Splunk, Microsoft Sentinel, Microsoft 365, databases, and other supported APIs.
No. A dedicated Abnormal Security connector is not required. Martini can use Abnormal Security's confirmed native REST API and OAuth 2.0 mechanisms. If a specific webhook or callback is confirmed for the required event, Martini can receive it through a webhook-triggered workflow; otherwise, scheduled polling is the safer pattern.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Abnormal Security. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Abnormal Security, cloud infrastructure, SIEM, ITSM, database, or other third-party systems based on subscription, usage, and deployment model.
Use the Abnormal Security REST APIs as the primary integration method and OAuth 2.0 for authentication. Collection retrieval and pagination support scheduled synchronization, while a separate bulk or asynchronous batch API was not confirmed. GraphQL and SOAP APIs were not confirmed and should not be assumed.
General-purpose webhook coverage for Threats, Cases, Messages, and other objects was not confirmed in the reviewed information. A tenant- or product-specific callback should be validated for each required event. If no suitable callback exists, Martini can poll the REST APIs on a schedule using incremental filters and checkpoints.
Martini can use supported timestamp, cursor, or updated-after filters, process paginated responses, and persist a checkpoint after successful writes. Stable Threat IDs, Case IDs, Message IDs, or Audit Log IDs should be stored as idempotency keys so retries and overlapping time windows do not create duplicate downstream records.
Yes. Martini can expose a controlled REST API backed by Abnormal Security data. The façade can centralize authentication, authorization, filtering, field mapping, and business rules so consuming applications do not need direct access to Abnormal Security credentials or tenant-specific API details.
Related Martini documentation
Workflows
Data
Operations
Connect Abnormal Security with your enterprise systems
Use Martini to build secure, maintainable Abnormal Security integrations around REST APIs, OAuth 2.0, scheduled synchronization, data mapping, business rules, and controlled downstream delivery.