[Beta] List available action and trigger types

List all available workflow action types and trigger types with their metadata. Use when managing deterministic workflow definitions and triggering or inspecting their runs.

GET /workflows/definitions

[Beta] List available action and trigger types

cURL

curl --request GET \
  --url http://localhost:8080/workflows/definitions \
  --header 'Authorization: Bearer <token>'

200

{
  "action_types": [
    {
      "type": "<string>",
      "name": "<string>",
      "description": "<string>",
      "category": "<string>",
      "icon": "<string>",
      "input_fields": [
        {
          "name": "<string>",
          "type": "<string>",
          "display_name": "<string>",
          "required": true,
          "description": "<string>"
        }
      ],
      "output_fields": [
        {
          "name": "<string>",
          "type": "<string>",
          "display_name": "<string>",
          "required": true,
          "description": "<string>"
        }
      ],
      "input_shape": "<unknown>",
      "output_shape": "<unknown>",
      "supported_trigger_types": [
        "<string>"
      ],
      "can_test": true
    }
  ],
  "trigger_types": [
    {
      "type": "<string>",
      "name": "<string>",
      "description": "<string>",
      "icon": "<string>",
      "payload_def": "<unknown>",
      "configuration_def": "<unknown>"
    }
  ],
  "block_types": [
    {
      "type": "<string>",
      "name": "<string>",
      "description": "<string>"
    }
  ],
  "operators": [
    {
      "name": "<string>",
      "display_name": "<string>",
      "type": "Unary",
      "applies_to": [
        "String"
      ]
    }
  ],
  "extra_variables": [
    "<unknown>"
  ]
}

Monitor session volume

Monitor Session Volume (monitor-session-volume) counts sessions created in a rolling window. It returns the total and links to a small sample. Add conditions, notifications, or other actions after it to build the behavior you need.

The node is available only in workflows with a Cron Trigger whose scheduled runs are at least five minutes apart (for example, */5 * * * *). Faster schedules are rejected at activation and execution, including for nested monitor nodes and schedules with a run limit of one. Other workflow triggers cannot activate or execute it. You can manually test a workflow whose saved trigger is cron. If the node is absent, it is not available on your deployment yet.

Configure the node

1. Create a cron workflow that runs every five minutes or less frequently.
2. Add Monitor Session Volume and set Window (minutes) to a whole number from 1 to 120. The default is 120 (two hours).
3. Optionally set Tag to an exact tag name. Leave it empty to count all eligible sessions. For example, a classification workflow could tag access reports, while this workflow counts sessions with that tag.
4. Add any downstream logic you need. For “more than eight sessions,” use an If/Else condition checking whether {{volume.count}} is greater than 8, where volume is the monitor node ID. Add notification actions in that branch.

The monitor has only two inputs: windowMinutes and optional tag. It has no threshold, reset timer, update interval, category grouping, source-date override, incident tracking, or notification destination. Tests of the monitor send nothing; notification actions added afterward can send real messages during workflow tests.

Outputs

Output	Meaning
count	Total matching sessions in the window. This is not limited to the sample size.
windowStart	Exclusive start of the evaluated window in ISO 8601 UTC.
windowEnd	Inclusive end of the evaluated window in ISO 8601 UTC.
sampleSessions	Up to ten newest matches, each with id, optional number, createdAt, and url.

Every execution reads current reporting data. Repeated or concurrent executions do not suppress one another. Add threshold checks, duplicate prevention, notification frequency controls, and delivery retries in downstream workflow steps as needed. A condition that remains true can therefore run its notification branch on every scheduled execution.

Counting behavior

The window is (now - window, now], using Open session creation time. Resolved sessions still count. Each session counts once, independent of its source channel or external system. Imports are measured from when the Open session was created; use an appropriate tag if historical imports should be excluded.

Spam and test billing exclusions, the Spam/Junk and companion-test tags, internal sessions, and child sessions are excluded. Counts are organization-scoped. Reporting data can lag newly created or updated sessions and tags. A successful query does not guarantee that every recent change has arrived. Query errors fail the workflow rather than returning zero or a partial count.

Updating an earlier draft

Remove the old threshold, reset/update timing, category, and source-creation inputs. Replace shouldAlert or thresholdReached conditions with comparisons against count. Incident IDs, category counts, and busy flags are no longer returned. Earlier Slack-specific drafts must also move their message configuration into a separate notification node. Review notification frequency before activating an existing draft, because the monitor no longer throttles it.

Snooze a session

Snooze Session (snooze-session) is available when native OpenCX ticketing and Settings → Workspace → Enable session snoozing are enabled. The definitions endpoint omits this action when it is unavailable.

Set ticketNumber to a session number in the current organization and durationMinutes to a finite number of at least 1. The output snoozedUntil is the scheduled wake-up time in ISO 8601 UTC. Duration is measured from step execution; the workflow continues immediately after applying Snooze.

The session must be open and human-assigned or unassigned, with no active call. The setting is checked again at execution, so disabling it also blocks already saved workflows from snoozing sessions. See session snoozing for wake-up, capacity, and SLA behavior.

The workflow editor provides duration presets and a custom minutes input; stored durationMinutes values and numeric references remain compatible. Workflow session payloads report ticketStatus: "snooze" while a session is snoozed. Session Updated emits a status change on entering or leaving Snooze, including the previous and new status values. A deadline change alone does not emit another status change.

Authorizations

Authorization · string · header · required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Response

200

application/json

Default Response

action_types · object[] · required

Available action types with their input/output schemas

Show child attributes

trigger_types · object[] · required

Available trigger types

Show child attributes

block_types · object[] · required

Available control-flow block types

Show child attributes

operators · object[] · required

Condition operators for if-else blocks, from the engine registry. This is the complete set the runtime evaluates — always pick "operatorName" from this list.

Show child attributes

extra_variables · any[] · required

Field schemas for the extra reference scopes available in every run, beyond the trigger payload and step outputs. Each entry's "name" is the scope root and its "properties" are the referenceable fields: {{metadata.}} (date/time of the run), {{run.}}, {{workflow.}}, {{organization.}}, and {{variables.}} for the organization's global variables. Leaf scopes have no "properties" and are referenced directly, e.g. {{routingSkills}} — a JSON string of every org skill (name + description).