.png)
Torq Integration Guide
Integrate Torq with enterprise systems through its REST APIs, workflow-specific webhook entry points, and outbound HTTP automation.
Torq integration options at a glance
Torq provides REST API access for programmatic interaction with workflows, workflow runs, and other platform resources, subject to the current API reference and permission model. Torq also supports workflow-specific webhook entry points, allowing external systems to submit HTTP requests that start automation. Configured Torq workflows can make outbound HTTP requests to Martini or other enterprise endpoints. Martini can consume Torq APIs, invoke webhook-triggered workflows, expose secured APIs for Torq callbacks, and use scheduled workflows for reconciliation or status polling where an event trigger is unavailable. Torq API credentials and connected-application credentials should be managed separately and stored securely in Martini Secrets Management.
| Integration point | Supported by Torq? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Programmatically retrieve or manage Torq platform resources, submit data, coordinate automation, and inspect workflow or execution status. Exact resources, operations, pagination, and filters should be confirmed in the current API reference. | Martini can consume Torq REST APIs from workflows, map responses, apply business rules, and write results to enterprise APIs, databases, or other supported endpoints. |
| Webhooks / inbound workflow triggers | Limited | Start a configured Torq workflow when an external system sends an HTTP request with the workflow-specific input payload. | Martini can invoke Torq webhook endpoints or expose an API that normalizes upstream events before invoking Torq. Coverage is workflow-specific rather than universal. |
| Outbound HTTP requests / callbacks | Limited | Allow a Torq workflow to call Martini or another enterprise endpoint after an event, decision, approval, or automation step. | Martini can expose secured REST APIs for callbacks, validate requests, process them idempotently, and return controlled responses. |
| Authentication | Yes | Authenticate Torq API requests with credentials generated and managed in the Torq environment. Connected applications may use separate OAuth, API token, service-account, or vendor-specific credentials. | Martini can store credentials in Secrets Management, configure environment-specific endpoints and headers, restrict access, and support credential rotation without changing workflow logic. |
| Scheduled synchronization | Yes | Reconcile workflow, run, or operational data when a required event is not available through a Torq webhook, subject to supported list, filter, timestamp, and status operations. | Martini scheduler-triggered workflows can paginate, checkpoint, throttle, transform, and retry Torq API requests. |
| Bulk / async / batch APIs | Not confirmed | No Torq-specific bulk or batch API was verified. Individual API operations may still support scheduled or incremental processing where the relevant resource allows it. | Martini can orchestrate repeated calls with pagination, checkpointing, throttling, and retry logic without claiming a Torq bulk API. |
| File / attachment APIs | Not confirmed | No general Torq file or attachment API was verified. File handling depends on the connected application, object-storage URL, HTTP payload, or other documented mechanism. | Martini can process files or HTTP payloads when the selected Torq use case exposes a supported endpoint, but the transfer contract must be confirmed first. |
| GraphQL APIs | Not confirmed | No official Torq GraphQL API was verified in the supplied research. | Martini can consume GraphQL APIs generally, but this integration should use Torq REST APIs unless current Torq documentation confirms GraphQL support. |
| SOAP APIs | No | No official Torq SOAP API was verified. | Martini can consume SOAP services generally, but SOAP should not be used as a Torq integration mechanism without new vendor confirmation. |
How Torq exposes data and business events
Torq REST APIs
Torq provides API-based platform access for programmatic interaction with resources such as workflows and workflow runs. The exact resource coverage, operations, authentication headers, pagination model, and permissions must be confirmed in the current Torq API reference.
Martini implementation pattern
Martini implementation pattern: a Martini workflow authenticates to Torq, requests the required resource, validates the response, maps Torq fields to a canonical model, and writes the result to an enterprise target. For asynchronous operations, Martini persists the execution identifier and polls a documented status resource or accepts a configured callback.
Implementation sequence
Torq Webhook Triggers
Torq supports workflow-specific webhook entry points that start a configured workflow when an external system submits an HTTP request. This is not a universal event stream for every Torq object or connected application.
Martini implementation pattern
Martini implementation pattern: an upstream system calls a secured Martini API or a Martini workflow receives a source event, validates and normalizes the payload, and invokes the selected Torq webhook endpoint. Martini records the request outcome and correlation identifier so retries do not create duplicate automation.
Implementation sequence
Torq Outbound HTTP Callbacks
Configured Torq workflows can make HTTP-based requests to Martini or other enterprise endpoints after an event, decision, approval, or workflow step. Delivery behavior depends on the workflow configuration and should be designed for retries and duplicate notifications.
Martini implementation pattern
Martini implementation pattern: Martini exposes a secured REST API, validates the Torq callback, applies routing and business rules, and updates a downstream application or publishes a message. The endpoint uses an idempotency key or stable workflow identifier when available and returns a controlled response to Torq.
Implementation sequence
Scheduled Torq Reconciliation
When a required event is not available through a Torq webhook, Martini can periodically call supported Torq REST resources to reconcile workflow, run, or operational status information. Pagination, filtering, and timestamp support must be confirmed for the selected resource.
Martini implementation pattern
Martini implementation pattern: a scheduler starts a workflow, retrieves pages or incremental results, transforms them, writes them to the target, and stores a durable checkpoint. Transient failures are retried with backoff, while permanent failures are surfaced for investigation.
Implementation sequence
Common Torq integration patterns
Pattern 1: Route enterprise events to Torq workflows
When to use this pattern
Use this pattern when several enterprise applications need to start Torq automation but their event formats differ. Martini provides a controlled API boundary, validates source authentication and required fields, selects the workflow by event type or severity, and sends a normalized payload to a Torq webhook trigger.
Integration direction
Example Mapping
| Torq Field | Canonical Field | Target Field |
|---|---|---|
| sourceEventId | correlationId | workflowInput.correlationId |
| alertSeverity | severity | workflowInput.severity |
| alertDescription | summary | workflowInput.summary |
| affectedResource | resourceIdentifier | workflowInput.resource |
Martini implementation pattern
Expose a Martini API for upstream events, validate the request, normalize the source schema, and apply routing rules to select the Torq workflow. Invoke the workflow-specific webhook, persist the response and correlation ID, and retry transient failures without replaying an already accepted event.
Martini capabilities used
- APIs
- workflows
- data mapping
- business rules
- Secrets Management
- error handling
Pattern 2: Send Torq callbacks to enterprise workflow systems
When to use this pattern
Use this pattern when Torq completes an investigation, remediation, approval, or notification step and an enterprise application must be updated. Martini centralizes callback validation and downstream routing instead of requiring every Torq workflow to implement a separate target contract.
Integration direction
Example Mapping
| Torq Field | Canonical Field | Target Field |
|---|---|---|
| workflowRunId | executionId | u_torq_execution_id |
| workflowStatus | automationStatus | state |
| workflowResult | resolutionSummary | close_notes |
| severity | priority | impact |
Martini implementation pattern
Expose a secured Martini callback API, validate the Torq request and execution identifier, deduplicate repeated callbacks, then map the result to ServiceNow or another target. Apply status and priority rules, retry transient downstream errors, and retain sanitized diagnostics for failed deliveries.
Martini capabilities used
- API exposure
- authentication
- data mapping
- business rules
- idempotency
- error handling
Pattern 3: Reconcile Torq workflow runs on a schedule
When to use this pattern
Use this pattern for status reporting, operational reconciliation, or event types that do not have a supported Torq webhook. Martini periodically retrieves the relevant Torq resource, processes pages or time windows, and updates a local database or enterprise application.
Integration direction
Example Mapping
| Torq Field | Canonical Field | Target Field |
|---|---|---|
| id | executionId | torq_execution_id |
| status | runStatus | status |
| startedAt | startedTimestamp | started_at |
| error | failureReason | failure_reason |
Martini implementation pattern
Use a scheduler-triggered workflow to load a checkpoint, call the documented Torq list or status resource, and process results incrementally. Validate response fields, persist successful records and the next checkpoint, throttle requests, and retry transient failures while isolating malformed results.
Martini capabilities used
- scheduler triggers
- API consumption
- pagination and checkpointing
- data transformation
- database integration
- retry handling
Pattern 4: Create a reusable Torq automation gateway
When to use this pattern
Use this pattern when multiple internal applications need a consistent API for invoking different Torq workflows. Martini hides workflow-specific endpoints behind a versioned internal contract and applies shared authentication, validation, routing, observability, and error policies.
Integration direction
Example Mapping
| Torq Field | Canonical Field | Target Field |
|---|---|---|
| automationType | workflowKey | selected Torq workflow |
| requestId | correlationId | workflowInput.correlationId |
| requester | requestedBy | workflowInput.requestedBy |
| parameters | normalizedParameters | workflowInput.parameters |
Martini implementation pattern
Expose a Martini REST API with a stable request contract, validate and normalize each request, select the Torq workflow using business rules, and invoke the corresponding webhook. Return an accepted response with correlation information where execution is asynchronous, and provide controlled handling for invalid workflows, timeouts, and downstream failures.
Martini capabilities used
- REST APIs
- workflow orchestration
- data mapping
- business rules
- authentication
- monitoring
- error handling
Applications commonly integrated with Torq
Torq commonly participates in security-operations and enterprise-automation architectures. The exact actions, triggers, permissions, and supported objects depend on the Torq workflow and the connected application configuration, so each implementation should be validated against the applicable product documentation.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| ServiceNow | Create or update incidents, synchronize assignment and priority, and coordinate remediation workflows. | Torq → Martini → ServiceNow | Martini can receive a Torq callback or consume Torq API data, normalize incident fields, apply routing and priority rules, and call ServiceNow APIs with correlation and retry handling. |
| Jira | Create investigation or remediation issues and synchronize ownership, status, and comments. | Torq → Martini → Jira | A Martini workflow can transform Torq workflow or investigation results into Jira issue payloads, route them by severity, and retry transient API failures while preventing duplicate issue creation. |
| Slack | Send security notifications, request analyst approval, and support operational workflow interactions. | Torq → Martini → Slack | Martini can receive normalized events, apply notification policies, and call Slack endpoints or pass approved actions to Torq using secured API requests and correlation identifiers. |
| Microsoft Teams | Deliver incident notifications and support collaboration or approval workflows in Microsoft 365 environments. | Torq → Martini → Microsoft Teams | Martini can validate Torq callbacks, map incident and approval data to Teams-compatible requests, and record response status for retry and operational reporting. |
| Okta | Automate identity response actions, access investigations, and account remediation. | Okta → Martini → Torq | Martini can receive Okta-related events or retrieve data through the relevant API, apply authorization and risk rules, and invoke a Torq webhook with a versioned workflow input contract. |
| Microsoft Sentinel | Initiate automated response from security alerts and return enrichment or remediation results. | Microsoft Sentinel → Martini → Torq | A Martini API can accept alert data, validate and normalize the payload, select the appropriate Torq workflow, and persist the Torq response or execution identifier for follow-up. |
| CrowdStrike Falcon | Enrich detections and coordinate endpoint containment or response actions. | CrowdStrike Falcon → Martini → Torq | Martini can transform detection data into a Torq workflow request, apply severity and approval rules, and expose a callback endpoint for completion updates where configured. |
| Google Workspace | Automate identity, email, or user-related response actions during security investigations. | Google Workspace → Martini → Torq | Martini can orchestrate requests between Google Workspace APIs and Torq, keep credentials in environment-specific secrets, and handle duplicate or delayed responses using correlation identifiers. |
How to build a Torq integration in Martini
Objective
Establish environment-specific access to Torq and any connected applications without embedding credentials in workflow logic.
Instructions in Martini
- Confirm the current Torq API authentication and permission requirements.
- Store Torq credentials in Martini Secrets Management.
- Configure Torq base URLs, headers, and target application credentials as environment-specific settings.
- Use separate development, test, and production credentials with planned rotation.
Objective
Select the event-driven or scheduled entry point that matches the required Torq integration behavior.
Instructions in Martini
- Use a Torq webhook trigger when the required workflow input and event are supported.
- Expose a secured Martini API when Torq must call Martini or when upstream systems need normalization.
- Use a scheduler for reconciliation, status polling, or event types without a suitable webhook.
Objective
Collect Torq requests or API responses and establish the correlation information needed for reliable processing.
Instructions in Martini
- Validate inbound authentication and required fields.
- Call the documented Torq REST resource or webhook endpoint.
- Capture workflow, run, event, or correlation identifiers when available.
- Handle pagination, time filters, and asynchronous status checks according to the current Torq API reference.
Objective
Coordinate the end-to-end processing path, including routing, enrichment, downstream calls, and asynchronous behavior.
Instructions in Martini
- Use Martini workflow steps to sequence API calls and transformations.
- Route requests to the appropriate Torq workflow based on source, event type, or severity.
- Persist execution identifiers when Torq automation completes asynchronously.
- Keep reusable mappings and integration logic separate from environment configuration.
Objective
Convert between upstream, Torq, and downstream schemas while enforcing workflow-specific contracts.
Instructions in Martini
- Validate required fields before invoking a Torq webhook.
- Map source fields to the selected Torq workflow input schema.
- Normalize timestamps, identifiers, status values, and severity values where required.
- Treat optional and nested fields defensively and version workflow-specific contracts.
Objective
Ensure that only authorized, valid, and appropriate automation requests reach Torq or downstream systems.
Instructions in Martini
- Apply source, severity, approval, and routing rules in Martini.
- Reject unsupported workflow keys or malformed payloads with controlled responses.
- Use correlation identifiers and idempotency checks to prevent duplicate actions.
- Avoid logging tokens or sensitive payload content.
Common Torq data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Workflows | Automated procedures composed of triggers, steps, conditions, actions, and integrations. | ServiceNow, Jira, Slack, Microsoft Teams, security platforms, and internal APIs | Martini can submit workflow inputs through Torq webhook endpoints, retrieve workflow information through the REST API, and route requests to different workflows using business rules. |
| Workflow runs | Individual workflow executions containing input data, execution state, results, and errors. | Operational databases, monitoring systems, ServiceNow, and reporting applications | Martini can retrieve or reconcile run information where exposed by the Torq API, persist execution identifiers, and use status checks or callbacks for asynchronous processing. |
| Triggers | Events or inbound requests that start Torq workflow execution. | Enterprise applications, Martini APIs, security tools, and connected applications | Martini can invoke webhook-based triggers, receive upstream events through its APIs, validate payloads, and normalize them into workflow-specific Torq input contracts. |
| Steps | Individual workflow operations such as HTTP requests, application actions, data processing, and conditional logic. | External APIs, security tools, collaboration applications, and enterprise services | Martini can supply validated data to Torq workflows and process callback or result data, while keeping cross-system mappings and reusable orchestration logic in Martini. |
| Subflows | Reusable workflow logic invoked from other Torq workflows. | Torq workflows and enterprise callback endpoints | Martini can treat subflow-related requests as workflow-specific API payloads, preserve correlation identifiers, and avoid assuming a universal subflow API contract. |
Authentication and security considerations
Credential management
Torq API credentials are generated and managed in the Torq environment. The exact token format, request headers, lifecycle, and permissions should be confirmed in the current Torq API documentation.
- Store Torq credentials and connected-application credentials in Martini Secrets Management.
- Use separate credentials for development, test, and production.
- Restrict permissions to the minimum required by each workflow.
- Rotate or revoke credentials without changing workflow logic.
API and callback security
Secure Martini APIs used for Torq callbacks with appropriate authentication and authorization. Validate request identity, required fields, correlation identifiers, and any available request signatures before processing.
- Do not hard-code tokens in workflows or mappings.
- Do not write authorization headers or sensitive payloads to logs.
- Use idempotency controls for retried callbacks and webhook requests.
Operational considerations for Torq integrations
Reliability and limits
Confirm Torq rate limits, quotas, pagination behavior, filtering options, and asynchronous status operations before implementation. Use bounded concurrency, exponential backoff for transient 429 and 5xx responses, and checkpoints for scheduled reconciliation.
Contracts and duplicates
Torq webhook inputs are workflow-specific. Maintain versioned contracts, validate required fields, and treat optional structures defensively. Use stable event, workflow run, or correlation identifiers to make retries safe and prevent duplicate downstream actions.
Monitoring and change management
- Record sanitized request outcomes, correlation IDs, execution IDs, and terminal failures.
- Distinguish accepted asynchronous execution from completed automation.
- Test representative workflow payloads before deployment.
- Monitor Torq API documentation and workflow schema changes.
- Define timeout, retry, and dead-letter or manual-reconciliation behavior for permanent failures.
Why use Martini instead of scripts or point-to-point integrations?
Centralized integration logic
Martini provides a maintainable place to expose APIs, consume Torq REST APIs, invoke workflow-specific webhooks, and process callbacks. This avoids duplicating authentication, validation, mappings, routing, and retry behavior across point-to-point scripts.
Reliable orchestration
Martini workflows can combine real-time requests, scheduled reconciliation, transformations, business rules, downstream writes, and error handling. Correlation identifiers, checkpoints, and idempotency controls support reliable operation when Torq automation is retried or completes asynchronously.
Reusable enterprise assets
Teams can isolate Torq-specific mappings and environment settings from broader orchestration logic, expose a stable API façade for internal applications, and reuse the same validation and security patterns across multiple Torq workflows.
Frequently asked questions
Torq can be integrated through its REST APIs, workflow-specific webhook entry points, and configured outbound HTTP requests. Enterprise systems can send normalized requests to Torq workflows, receive Torq callbacks through secured APIs, or use scheduled API synchronization when a required event is not available.
Yes. Martini can consume Torq REST APIs, invoke Torq webhook-triggered workflows, and expose secured APIs for Torq outbound callbacks. Martini can also orchestrate scheduled reconciliation and transform Torq data for enterprise targets.
No. A dedicated Torq connector is not required. Martini can integrate using Torq's documented REST APIs, webhook endpoints, outbound HTTP mechanisms, and authentication methods confirmed for the selected use case.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Torq. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Torq, cloud infrastructure, or other third-party systems based on subscriptions, usage, and deployment model.
Use Torq REST APIs for programmatic resource access and status retrieval, and use workflow-specific webhook entry points for event-driven automation when the required workflow input is available. Use outbound HTTP callbacks when Torq must notify Martini, and scheduled API workflows for reconciliation. GraphQL and SOAP were not confirmed as Torq integration methods.
Torq supports webhook-style workflow triggers and configured HTTP interactions, but this is not a universal event stream. Availability depends on the workflow, connected application, and event type. Martini can invoke supported Torq webhook endpoints or use scheduled REST API polling when a suitable webhook is unavailable.
A Martini workflow can retrieve supported Torq resources through the REST API, map them to a canonical model, apply business rules, and write them to another API, database, or supported endpoint. Scheduled processing can use pagination, filters, timestamps, checkpoints, and retries where the Torq resource supports them.
Martini can distinguish authentication failures, invalid workflow input, missing endpoints, rate limits, timeouts, platform errors, and downstream failures. Workflows can retry transient responses with backoff, preserve correlation identifiers, and use stable event or workflow run IDs for idempotency. A Martini API façade can also expose a controlled contract for Torq automation and callbacks.
Related Martini documentation
Workflows
Integrate Torq with Martini
Use Martini to connect Torq automation with enterprise APIs, applications, databases, and operational workflows through secure, maintainable integrations.