.png)
Orca Security Integration Guide
Connect Orca Security cloud-security findings and platform data with enterprise systems through REST APIs, scheduled workflows, and selected outbound notifications.
Orca Security integration options at a glance
Orca Security provides REST APIs for retrieving cloud accounts, assets, alerts, vulnerabilities, compliance issues, and other platform data. API-token authentication is the primary confirmed access method. Integrations should use documented filtering and pagination for scheduled or incremental synchronization, with rate-aware retries and checkpoints for large inventories. Orca Security also provides selected integrations and notification destinations, but universal webhook coverage for every object change is not confirmed. Martini can consume the REST API, map findings into operational or analytics systems, expose a normalized API, and receive supported outbound callbacks when the relevant Orca feature provides them.
| Integration point | Supported by Orca Security? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Retrieve cloud accounts, assets, alerts, vulnerabilities, and compliance issues; apply filters; and synchronize security data with downstream systems. | Martini can consume the Orca Security REST API from workflows, manage pagination and checkpoints, transform responses, and write results to APIs, databases, or files. |
| Webhooks and outbound callbacks | Limited | Selected Orca integrations and notification destinations may provide outbound notifications for particular security workflows or events. | Martini can expose a receiving API or workflow endpoint and process a supported callback, but the event types, retry behavior, signing, and payload schema must be verified for the specific Orca feature. |
| Authentication | Yes | API tokens provide the primary confirmed authentication method for programmatic Orca Security access, subject to tenant permissions and required headers. | Martini stores the token in environment configuration or secrets and applies it to API requests without embedding credentials in workflow definitions or logs. |
| Scheduled synchronization | Yes | Scheduled REST extraction is appropriate when event coverage is unavailable or incomplete, including periodic asset, vulnerability, alert, and compliance synchronization. | Martini scheduler-triggered workflows can retrieve filtered pages, maintain a watermark, use overlap windows, and upsert changed objects. |
| Filtering and pagination | Yes | Large cloud-account, asset, and finding collections should be retrieved with documented filters, page sizes, and continuation or offset behavior. | Martini workflows can iterate through pages, checkpoint progress, recover from interruptions, and avoid repeatedly processing the same page. |
| Bulk or asynchronous APIs | Not confirmed | The reviewed material does not establish a separate bulk or asynchronous API for all Orca Security objects. | Martini should use documented REST pagination and filtering unless tenant-specific Orca documentation confirms a bulk or asynchronous endpoint. |
| File and attachment APIs | Not confirmed | Product-specific reports or exports may exist, but a general-purpose file or attachment API was not confirmed. | Martini can process documented exports or files if provided, but workflows should not assume attachment objects are available for every finding. |
| Database or analytics access | No | Direct Orca Security database access was not confirmed; integrations should use APIs or documented exports. | Martini can write API results to supported databases or analytics destinations without connecting directly to Orca's internal database. |
How Orca Security exposes data and business events
Orca Security REST APIs
Orca Security exposes REST APIs for programmatic access to cloud accounts, assets, alerts, vulnerabilities, compliance issues, and platform operations. Endpoint availability, filters, identifiers, page sizes, and object operations can vary by API version and tenant configuration.
Martini implementation pattern
Martini implementation pattern: a scheduled or API-triggered workflow authenticates with an Orca API token, requests filtered pages, transforms the response into a canonical security model, applies business rules, and writes or upserts data in the target system. The workflow records checkpoints and handles rate limits, transient errors, and changed schemas.
Implementation sequence
Scheduled synchronization
Scheduled extraction is the principal fallback when Orca Security does not provide a confirmed notification for every asset, alert, vulnerability, or compliance change. Separate workflows can manage different data volumes and recovery boundaries.
Martini implementation pattern
Martini implementation pattern: a scheduler starts an extraction workflow, which requests changes within an overlap window, follows pagination, writes target records idempotently, and stores the latest successful watermark. Separate workflows can synchronize cloud accounts, assets, alerts, vulnerabilities, and compliance issues independently.
Implementation sequence
Outbound notifications
Orca Security supports selected integrations and notification destinations, but a general-purpose webhook API covering all object changes was not confirmed. Event types, payloads, signing, and retry semantics must be verified for the relevant feature.
Martini implementation pattern
Martini implementation pattern: where Orca provides a supported callback, Martini exposes a receiving API or workflow endpoint, validates the incoming request, retrieves current source data when necessary, applies routing and deduplication rules, and forwards the result to the target system. Scheduled reconciliation can supplement limited event coverage.
Implementation sequence
Common Orca Security integration patterns
Pattern 1: Route findings to ServiceNow
When to use this pattern
Use this pattern when security operations need incidents or remediation tasks for prioritized Orca Security alerts, vulnerabilities, or compliance issues. Scheduled REST polling is appropriate when a supported event for the required finding type is not confirmed.
Integration direction
Example Mapping
| Orca Security Field | Canonical Field | Target Field |
|---|---|---|
| finding identifier | sourceFindingId | u_orca_finding_id |
| severity | severity | priority |
| status | lifecycleStatus | state |
| asset or cloud account | resourceContext | configuration item |
Martini implementation pattern
A Martini workflow retrieves changed findings, filters by severity and status, enriches ownership from cloud-account or team data, and searches ServiceNow for the source identifier before creating or updating an incident. Validation rejects incomplete records, while transient API failures use bounded retries and authentication failures are surfaced for operator action.
Martini capabilities used
- workflows
- API consumption
- scheduling
- data mapping
- business rules
- error handling
Pattern 2: Create Jira remediation work
When to use this pattern
Use this pattern when engineering teams manage remediation in Jira and need actionable issues for high-severity vulnerabilities or cloud-security findings. The workflow should preserve the Orca identifier and update the issue as the source finding changes.
Integration direction
Example Mapping
| Orca Security Field | Canonical Field | Target Field |
|---|---|---|
| vulnerability identifier | sourceFindingId | external reference |
| title and description | remediationSummary | summary and description |
| severity | severity | priority |
| owner or team | assignedTeam | assignee or component |
Martini implementation pattern
Martini extracts qualifying findings, maps severity and affected-asset context, selects the Jira project and component, and uses the Orca identifier as the deduplication key. Business rules can avoid issue creation for accepted or suppressed findings, and retry handling separates rate limits from validation or permission errors.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
Pattern 3: Notify teams about critical alerts
When to use this pattern
Use this pattern for concise operational notifications to Slack, Microsoft Teams, or PagerDuty when critical findings require rapid attention. Because universal Orca webhook coverage is not confirmed, implement polling or a verified outbound notification for the selected event type.
Integration direction
Example Mapping
| Orca Security Field | Canonical Field | Target Field |
|---|---|---|
| alert identifier | alertId | message correlation key |
| severity | severity | notification priority |
| asset and cloud account | resourceContext | message context |
| status | lifecycleStatus | thread or incident state |
Martini implementation pattern
A Martini workflow receives a confirmed notification or retrieves recent alerts, applies criticality and routing rules, formats a compact message, and sends it to the selected channel or incident endpoint. It records the alert identifier to prevent repeated notifications and uses a reconciliation workflow to handle missed events.
Martini capabilities used
- workflows
- API consumption
- webhook receiving
- data mapping
- routing rules
- error handling
Pattern 4: Load security findings into analytics
When to use this pattern
Use this pattern when an organization needs historical Orca Security assets, vulnerabilities, alerts, and compliance issues in Splunk, Microsoft Sentinel, a data warehouse, or another analytics platform. Direct Orca database access is not assumed.
Integration direction
Example Mapping
| Orca Security Field | Canonical Field | Target Field |
|---|---|---|
| cloud account | cloudAccountId | account identifier |
| asset identifier | resourceId | resource identifier |
| finding status | lifecycleStatus | status |
| updated timestamp | sourceUpdatedAt | event timestamp |
Martini implementation pattern
Separate scheduled Martini workflows extract each high-volume object type, follow documented pagination, normalize nested security fields, and write records using stable source identifiers. Checkpoints and overlap windows support recovery and late updates, while schema-tolerant mappings handle optional fields and new enumeration values.
Martini capabilities used
- workflows
- scheduling
- API consumption
- pagination
- data mapping
- database or API delivery
- monitoring
Applications commonly integrated with Orca Security
Orca Security data can be routed to security operations, engineering, collaboration, on-call, and analytics products. The exact Orca event or integration coverage should be verified for each destination; where no supported outbound event exists, Martini can use scheduled REST API extraction.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create or update security incidents, remediation tasks, and ownership work items from prioritized Orca Security findings. | Orca Security → Martini → ServiceNow | A scheduled Martini workflow retrieves changed alerts, vulnerabilities, or compliance issues, maps severity and ownership, searches ServiceNow using the Orca identifier, and creates or updates the corresponding record with bounded retries. |
| Jira | Track vulnerability and cloud-security remediation work with engineering teams. | Orca Security → Martini → Jira | Martini filters qualifying findings, maps cloud accounts and assets to Jira projects and teams, deduplicates by the Orca finding identifier, and updates the issue when status or severity changes. |
| Slack | Send selected high-severity findings to security and cloud operations channels. | Orca Security → Martini → Slack | Martini polls or processes a supported Orca notification, applies severity and ownership rules, formats a concise message, and routes it to the appropriate Slack channel while preventing duplicate notifications. |
| Microsoft Teams | Route security findings and operational notifications to collaboration channels. | Orca Security → Martini → Microsoft Teams | A Martini workflow transforms qualifying Orca findings into Teams messages, selects channels by business unit or cloud account, and records the source identifier for idempotent processing. |
| PagerDuty | Escalate critical cloud-security alerts to on-call responders. | Orca Security → Martini → PagerDuty | Martini maps critical Orca alerts to PagerDuty incidents, applies deduplication and escalation rules, and closes or updates incidents when the source finding reaches a supported resolved state. |
| Splunk | Centralize Orca alerts and findings for investigation, correlation, and reporting. | Orca Security → Martini → Splunk | A scheduled workflow extracts paginated Orca data, normalizes nested fields into the target event model, enriches records with cloud-account context, and writes them using stable identifiers and checkpointed progress. |
| AWS Security Hub | Correlate Orca cloud-security findings with AWS-native security findings. | Orca Security → Martini → AWS Security Hub | Martini maps Orca severity, resource, account, and finding status into the target finding model, validates required AWS fields, and upserts findings while retaining the Orca source identifier. |
| Microsoft Sentinel | Correlate Orca findings with broader identity, endpoint, and cloud telemetry. | Orca Security → Martini → Microsoft Sentinel | Martini performs scheduled extraction or handles a confirmed notification, transforms Orca findings into the Sentinel ingestion model, applies filtering and enrichment, and retries transient delivery failures. |
How to build a Orca Security integration in Martini
Objective
Establish secure access to the Orca Security API and confirm that the token has only the permissions required for the selected objects and operations.
Instructions in Martini
- Create or obtain an Orca Security API token with the required tenant permissions
- Store the token in Martini secrets or environment configuration
- Confirm the tenant API base URL, version, headers, and page-size limits
- Verify that credentials are excluded from workflow definitions and logs
Objective
Select scheduled extraction as the default trigger unless Orca Security provides a verified outbound notification for the required event type.
Instructions in Martini
- Use a scheduler for periodic or incremental synchronization
- Use a Martini receiving API only for a confirmed Orca callback or notification
- Define separate schedules when assets, alerts, vulnerabilities, and compliance issues have different volumes or priorities
Objective
Call the relevant Orca Security REST endpoints and retrieve complete, filtered result sets without losing progress during large synchronizations.
Instructions in Martini
- Apply documented filters and an overlap window where timestamps are available
- Process pages using the tenant's continuation or offset method
- Persist progress or checkpoints after successful page handling
- Classify rate-limit, authentication, validation, missing-object, and service errors separately
Objective
Coordinate extraction, enrichment, business rules, target delivery, and reconciliation in a maintainable Martini workflow.
Instructions in Martini
- Pass normalized context between workflow stages
- Use reusable services or subflows for common API and error-handling logic
- Separate high-volume object types when independent recovery is useful
- Add reconciliation polling when outbound notification coverage is incomplete
Objective
Transform Orca Security objects into the target system's security, incident, issue, notification, or analytics model.
Instructions in Martini
- Map stable Orca identifiers to target external identifiers
- Define explicit severity, status, ownership, cloud-account, and asset mappings
- Handle optional nested values and provider-specific resource fields
- Preserve source timestamps and relevant source context
Objective
Control which findings are delivered and how they are routed, deduplicated, and updated.
Instructions in Martini
- Filter by severity, status, cloud account, asset, or ownership requirements
- Skip or update accepted and suppressed findings according to policy
- Search for an existing target record before creating a new one
- Use bounded retries and avoid indefinite retries for authorization failures
Common Orca Security data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Cloud accounts | Represent AWS, Azure, and other connected cloud environments monitored by Orca Security. | ServiceNow, Splunk, Microsoft Sentinel, AWS Security Hub, data warehouses | Martini retrieves account identifiers and attributes through the REST API, normalizes provider-specific fields, and uses stable identifiers for upserts and ownership routing. |
| Assets | Represent cloud resources and workloads discovered and assessed by Orca Security. | ServiceNow, Splunk, Microsoft Sentinel, operational databases | Martini processes assets in paginated batches, preserves cloud-account and resource context, and tolerates optional or provider-specific fields. |
| Alerts | Represent prioritized security notifications requiring investigation or remediation. | ServiceNow, Jira, PagerDuty, Slack, Microsoft Teams, SIEM platforms | Martini maps severity, status, ownership, timestamps, and source identifiers, then applies deduplication and routing rules before delivery. |
| Vulnerabilities | Represent vulnerability findings associated with assets or workloads. | Jira, ServiceNow, Splunk, Microsoft Sentinel, security data warehouses | Martini extracts changed vulnerabilities, maps lifecycle states and affected assets, and upserts them using the Orca vulnerability identifier. |
| Compliance issues | Represent cloud security posture, compliance-control, or policy-violation findings. | ServiceNow, Jira, Splunk, AWS Security Hub, Microsoft Sentinel | Martini transforms control, framework, severity, ownership, and status fields and preserves the original Orca identifiers for reconciliation. |
| Users and teams | Represent users, ownership assignments, or organizational groups used for notification and remediation routing. | ServiceNow, Jira, Slack, Microsoft Teams, PagerDuty | Martini can use users and teams as lookup data for routing and assignment, subject to the available API operations and token permissions. |
Authentication and security considerations
API-token authentication
Orca Security API access is primarily based on API tokens. Confirm the tenant-specific API version, authorization header, token permissions, and endpoint access before production use.
Credential protection
Store the token in Martini environment configuration or secrets management. Do not embed credentials in workflow definitions, mappings, source code, or log messages.
Least privilege and sensitive findings
- Assign only the permissions required for the selected Orca objects and operations.
- Restrict downstream data to the security context required by each receiving system.
- Protect infrastructure identifiers, host details, policy information, and remediation data.
- Use secured API endpoints and validate supported inbound callbacks before processing them.
Operational considerations for Orca Security integrations
Pagination and volume
Assets and findings can be large collections. Use documented page sizes, continuation or offset handling, checkpoints, and separate workflows for major object types where useful.
Incremental synchronization
Use supported update filters and a persisted watermark with a small overlap window. This helps account for delayed updates and interrupted runs.
Rate limits and retries
Apply bounded retries with exponential backoff for transient failures and rate-limit responses. Do not retry authentication or authorization failures indefinitely.
Idempotency and schema changes
Use stable Orca identifiers to update existing target records rather than creating duplicates. Keep mappings tolerant of optional nested fields, new cloud-resource types, and changed enumeration values.
Event coverage and testing
Do not assume universal webhook coverage. Test the selected API version, filters, permissions, payloads, target mappings, and recovery behavior against representative assets and findings before production deployment.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration beyond scripts
Martini provides a maintainable workflow layer for authentication, pagination, filtering, transformation, routing, target delivery, and reconciliation instead of embedding all behavior in a one-off script.
Reusable integration assets
Teams can expose a normalized API, reuse mapping and error-handling logic, and apply consistent business rules across ServiceNow, Jira, notification, SIEM, and data-warehouse destinations.
Operational reliability
- Run scheduled or event-assisted synchronization workflows.
- Use checkpoints, idempotency keys, bounded retries, and overlap windows.
- Keep credentials in secure configuration rather than code.
- Monitor execution and troubleshoot failures through centralized workflow operations.
Frequently asked questions
Orca Security can be integrated through its REST APIs using API-token authentication. Enterprise workflows can retrieve cloud accounts, assets, alerts, vulnerabilities, and compliance issues, then synchronize them to service-management, remediation, notification, SIEM, or analytics systems. Scheduled extraction with pagination, filtering, checkpoints, and idempotent upserts is the primary broadly confirmed pattern; selected outbound notifications may support event-driven processing.
Yes. Martini can consume the Orca Security REST API, authenticate with an API token stored in secrets, orchestrate scheduled or API-triggered workflows, transform security data, and deliver it to downstream systems. Martini can also receive a supported Orca callback when the relevant feature provides one, although universal event coverage is not confirmed.
No. A dedicated Orca Security connector is not required. Martini can integrate using Orca Security's confirmed REST APIs, API-token authentication, scheduled workflows, and any supported outbound notification or callback endpoints for the selected use case.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Orca Security. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Orca Security, target applications, cloud infrastructure, or other third-party services depending on subscriptions, usage, and deployment model.
The documented Orca Security REST APIs and API-token authentication should be the foundation for new integrations. Use filtering and pagination for large collections, scheduled workflows for incremental synchronization, and a verified outbound notification only when the relevant Orca feature documents the event, payload, and delivery behavior. A public GraphQL or SOAP API was not confirmed.
Only for a specific Orca Security feature that provides a supported outbound callback, webhook, or notification endpoint. General webhook coverage for all assets, vulnerabilities, alerts, and compliance changes was not confirmed. Where event coverage is limited, Martini can use scheduled REST polling and reconciliation.
Martini can retrieve filtered and paginated objects, use an update watermark with an overlap window, map Orca severity, status, ownership, asset, and cloud-account fields into a canonical model, and upsert target records using stable Orca identifiers. Business rules can route or suppress findings based on severity, lifecycle state, team, or cloud environment.
A Martini workflow can classify authentication, authorization, validation, rate-limit, missing-object, and temporary service failures separately. Bounded retries with exponential backoff are suitable for transient errors, while stable Orca identifiers provide idempotency and deduplication. Checkpoints and reconciliation reduce repeated processing after interrupted synchronization.
Related Martini documentation
Workflows
Operations
Connect Orca Security with Martini
Use Martini to build secure, maintainable Orca Security integrations for findings synchronization, remediation workflows, notifications, and security analytics.