Skip to main content

Torq

Bring your Torq SOC operations into the JupiterOne graph — cases with the lifecycle timestamps and SLA data behind resolution-time and case-volume reporting, the analysts they are assigned to, and the runbooks they follow. For workspaces licensed for Auto Triage (HyperSOC), alerts are ingested alongside, carrying the detection, acknowledgement and triage timestamps and the triage verdict that underpin acknowledgement-time, triage-latency and true-positive-rate reporting, each linked to the case it produced. The integration collects metadata only: case descriptions, analyst notes, comments, attachments and runbook bodies are never retrieved.

Installation​

Prerequisites​

  • A Torq workspace, and an API key created in it.
  • If you want alert data, a workspace licensed for Auto Triage (HyperSOC). Case data does not require it — see Auto Triage is licensed separately.
  • Access to JupiterOne with permission to configure integrations.

Create an API key in Torq​

The integration authenticates using OAuth 2.0 (client credentials), exchanging the API key's Client ID and Client Secret for a bearer token. Tokens are valid for one hour and are renewed automatically during a run.

To create the key:

  1. Sign in to Torq.
  2. Go to Settings → API Keys.
  3. Create a new API key and copy the Client ID and Client Secret. The secret is shown only once.

An API key is scoped to the workspace it is created in, so a JupiterOne instance collects from exactly one Torq workspace. To cover several workspaces, create one integration instance per workspace.

The integration issues read-only requests.

Configuration in JupiterOne​

To install the Torq integration in JupiterOne, navigate to the Integrations tab in JupiterOne and select Torq. Click New Instance to begin configuring your integration.

Creating an instance requires the following:

  • The Account Name used to identify the Torq account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.

  • Description to assist in identifying the integration instance, if desired.

  • Polling Interval that you feel is sufficient for your monitoring needs. You may leave this as DISABLED and manually execute the integration.

  • The Authentication fields below.

Authentication fields​

FieldRequiredDescription
RegionYesThe Torq region hosting your workspace. Choose EU only if you sign in at eu.torq.io; otherwise leave it as United States.
Client IDYesClient ID of the Torq API key.
Client SecretYesClient Secret paired with the Client ID. Shown only once when the key is created.

Click Create once all values are provided to finalize the integration.

note

Region selects both the API and authentication hosts — api.torq.io and auth.torq.io for the United States, api.eu.torq.io and auth.eu.torq.io for Europe. An API key issued in one region will not authenticate against the other.

Data collection fields​

These are optional and control how much history each run collects.

FieldDefaultDescription
Case Lookback Days90 daysHow far back to collect cases on each sync, by case creation date. Options are 30, 90, 180 and 365 days, or All time.
Alert Lookback Days30 daysHow far back to collect Auto Triage alerts on each sync, by acknowledgement time. Options are 7, 30 and 90 days. Only applies when the Auto Triage Alerts ingestion source is enabled.
caution

Case Lookback Days is a rolling window over case creation date. A case created before the window is removed from JupiterOne on the next run, even if it is still open. Choose All time if you need the full history retained.

Torq does not serve alerts acknowledged more than 90 days ago, which is why Alert Lookback Days stops at 90.

Data sources​

You can narrow what the integration collects from the instance's ingestion source settings.

Ingestion sourceDefaultData collected
CasesEnabledTorq cases with their lifecycle timestamps, severity, category and SLA, for resolution-time and case-volume reporting.
UsersEnabledUser accounts in the Torq workspace.
RolesEnabledRoles available in the workspace and the permission scopes they grant.
User Role AssignmentsEnabledWhich role each Torq user holds.
RunbooksEnabledCase runbooks defined in the workspace. Metadata only — the runbook body is not retrieved.
Case AssignmentsEnabledWhich Torq user each case is assigned to.
Case RunbooksEnabledWhich runbook each case follows.
Auto Triage AlertsDisabledAlerts triaged by Torq Auto Triage that resulted in a case, carrying detection, acknowledgement and triage timestamps plus the triage verdict.
Alert Case LinksDisabledWhich case each Auto Triage alert produced. Requires Auto Triage Alerts.
Case RelationsDisabledParent, duplicate and blocking relations between cases.

Relationships that span two sources are only created when both are enabled. Disabling Users, for example, does not stop cases being collected — it removes the assignment edges between them.

The three disabled sources​

Auto Triage Alerts requires a workspace licensed for Auto Triage, and alerts are the highest-volume object in Torq — Auto Triage exists to collapse many alerts into far fewer cases. The collection is bounded in two ways: to alerts that actually produced a case, and to the configured lookback window. That keeps the volume close to case count rather than one to two orders of magnitude above it.

Alert Case Links depends on Auto Triage Alerts and adds no requests of its own.

Case Relations is disabled for cost rather than volume: Torq exposes links only per case, so enabling it issues one additional API request for every case collected.

Auto Triage is licensed separately​

Auto Triage (HyperSOC) is a separately licensed Torq capability. On a workspace without it, the alert endpoints return 403, while cases, users, roles and runbooks are unaffected.

The integration is built for this. Setup validates the credentials by requesting a token and nothing more, so an unlicensed workspace configures normally. If Auto Triage Alerts is enabled on a workspace that lacks the licence, the step records a missing-permission warning and the run continues — the remaining sources are collected as usual.

What the integration does not collect​

The integration is designed to collect the minimum needed for reporting and relationship mapping. It never retrieves:

  • Case descriptions, titles, analyst notes, comments or attachments
  • Resolution write-ups or case review notes
  • Auto Triage narrative output — alert summaries, verdict justifications and suggested actions
  • Runbook bodies

Cases are named by their Torq pretty ID (for example #4812) rather than their title, following the same convention as the ServiceNow and Jira integrations. Alert names are collected, because they are the detection rule name reported by the source security tool — for example Endpoint Detection - ldt — rather than analyst-authored text.

The case timeline, notes, comments and attachment endpoints are never called at all.

Next steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. Continue on to our Instance management guide to learn more about working with and editing integration instances.

Additional resources​