Actions

An action is the universal callable unit on the platform. Every operation that can be executed — whether it's a native platform service function, an external REST API call, or a step in a flow — is represented and invoked as an action.

This uniform interface means that flows, agents, and application code interact with all operations the same way, regardless of their underlying implementation.

Action properties

Every action has a consistent structure:

Runners

The runner field determines how an action is executed:

Native runner

Native actions call registered platform service operations — Go functions that are part of the platform's internal services.

The targetId format is {serviceName}/{operationName}. For example: conversations/CreateConversation or datasets/QueryDataset.

Native actions include platform operations like creating conversations, running flows, querying datasets, and managing collections.

Integration runner

Integration actions call external APIs through the platform's integration engine.

The targetId format is {integrationUID}/{operationID}. For example: uint_salesforce123/listContacts.

The integration engine handles HTTP request construction, authentication injection from connections, parameter mapping, and response transformation.

Action identifiers

Actions are referenced using structured identifiers that include the blueprint context:

{blueprintName}-{blueprintUID}@{major}.{minor}/actions/{actionUID}

For example:

[email protected]/actions/uact_listFiles

This format ensures actions can be unambiguously referenced across blueprints and versions.

Calling an action

All action calls go through a single API endpoint:

POST /v1/apps/{appUid}/actions/call

{
  "actionIdentifier": "[email protected]/actions/uact_listFiles",
  "connectionId": "conn_xyz",
  "input": { "folderId": "root" },
  "waitForResult": true
}

The platform resolves the action identifier, determines the runner, and dispatches execution:

CallAction
├── Parse action identifier
├── Resolve App → Blueprint → Action
├── Create Task (tracks execution)
│
├── runner == "native"
│   └── Call registered service operation
│
└── runner == "integration"
    ├── Load integration definition and operation
    ├── Build HTTP request (method, URL, headers, body)
    ├── Inject authentication from connection
    ├── Send request
    ├── Apply output transforms
    └── Return result

Task tracking

Every action call creates a task that tracks execution state:

Created → Queued → Scheduled → Running → Completed
                                   └──→ Failed

Tasks record:

• Input parameters
• Output data
• Error details (if failed)
• Timing information (start, end, duration)
• Parent task references (for nested calls within flows)

When an action is called asynchronously, the task ID is returned immediately. You can poll the task status or subscribe to its completion event.

How actions are created

Actions are added to blueprints in two ways:

1. From integrations — when an integration is created or updated, each operation is automatically synced as an action in the blueprint. The action UID is deterministically generated from the integration UID and operation ID.

2. From platform services — native services register their operations at startup. Each operation becomes a callable action with auto-generated input/output schemas derived from the function signatures.

Action kinds

The kind field describes the execution pattern:

Related concepts

• Apps — the context in which actions are called
• Blueprints — where actions are defined
• Integrations — how external API operations become actions
• Flows — workflows that chain multiple action calls