Run Analyzer
cortex.run_analyzer
ActionBusiness appsconnection required
Calls the Cortex API with the connection's credentials.
Submit one observable to an analyzer and return the queued job.
Connection
- Required
- Yes — the node will not save without one
- Auth type
- Bearer token
- Providers
- Cortex
- Secret shape
- the Cortex organisation API key, or {"api_key": "…"}
- Config it needs
- base_url
- Resolved by
- config.connection_id, else node.connection_id
Configuration
9 fields, 3 required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.
| Field | Type | Required | Default | Constraints | Example |
|---|---|---|---|---|---|
analyzer_id Cortex's id for the analyzer to run, as returned by cortex.list_analyzers. It is not the analyzer's name. | string | Yes | — | — | — |
data_type The observable's type, as one of the types the analyzer lists in its dataTypeList — ip, domain, url, hash, mail and so on. The 'file' type needs a multipart upload and is not supported here. | string | Yes | — | — | ip |
data The observable itself, such as the IP address or hash to analyse. | string | Yes | — | — | 8.8.8.8 |
tlp The Traffic Light Protocol level to attach to the job, from 0 (white) to 3 (red). Cortex uses 2 when this is left blank. | integer | No | 2 | 0–3 | — |
pap The Permissible Actions Protocol level to attach to the job, from 0 to 3. It tells the worker how visible its actions may be. Cortex uses 2 when this is left blank. | integer | No | 2 | 0–3 | — |
message Free-text context to store alongside the job, such as the case it came from. | string | No | — | — | — |
label A short label to store on the job so it can be found again. | string | No | — | — | — |
parameters Worker-specific parameters, as a JSON object. Each worker publishes its own; leave it empty to use the configured defaults. | object | No | — | — | — |
force Run the analyzer again even when Cortex has a cached report for this observable. | boolean | No | — | — | — |
Example configuration
Every value below is the contract’s own example or default — nothing invented.
{
"data": "8.8.8.8",
"data_type": "ip",
"pap": 2,
"tlp": 2
}Output
One shape.
result
| Field | Type | Example |
|---|---|---|
id Cortex's id for the job — what the report nodes are given. | string | — |
analyzerId Id of the worker that runs the job. | string | — |
analyzerName Name of the worker that runs the job. | string | — |
analyzerDefinitionId Catalogue definition of that worker. | string | — |
status Where the job is: Waiting, InProgress, Success, Failure or Deleted. | string | — |
dataType The observable or record type the job was given. | string | — |
data The observable the job was given. | string | — |
tlp The Traffic Light Protocol level the job carries. | number | — |
pap The Permissible Actions Protocol level the job carries. | number | — |
message The context message sent with the job. | string | — |
errorMessage Why the worker failed, when it did. | string | — |
parameters The parameters the job was started with. | object | — |
organization The Cortex organisation the job belongs to. | string | — |
type Either 'analyzer' or 'responder'. | string | — |
label The label given to the job, if any. | string | — |
date When the job was created, as an ISO-8601 timestamp. | string | — |
startDate When the worker started, as an ISO-8601 timestamp. | string | — |
endDate When the worker finished, as an ISO-8601 timestamp. | string | — |
{
"analyzerDefinitionId": "",
"analyzerId": "",
"analyzerName": "",
"data": "",
"dataType": "",
"date": "",
"endDate": "",
"errorMessage": "",
"id": "",
"label": "",
"message": "",
"organization": "",
"pap": 0,
"parameters": {},
"startDate": "",
"status": "",
"tlp": 0,
"type": ""
}See Run Analyzer run in a workflow.
In a technical demo we add the Cortex connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.