Operator Catalog

An operator is the verb in a flow — a typed, named, versioned function with declared inputs, outputs, and actions. Zenvara ships a focused catalog (50+ operators) organised into six packs, plus three runtime-native transformers and a generic HTTP/SOAP layer that adapts to any OpenAPI or WSDL service.

The source of truth for any operator’s exact fields is its own definition.yaml — the type provider surfaces those fields as editor autocomplete, and an MCP-aware assistant reads the live catalog directly. These pages give you the map; the definition gives you the field-level contract.

Categories

Category	What’s in it
AI Operators	Claude, ChatGPT, Gemini, Claude CLI, web search. LLM calls as typed pipeline steps.
Data & Databases	PostgreSQL, MS-SQL, MySQL, Oracle, MongoDB, Redshift — plus the join / delta / filter transformers.
I/O & Files	Filesystem, SFTP, SSH, S3, Dropbox, Archive, HTTP, REST, GraphQL, SOAP/WSDL, Kinesis.
Integrations	Akeneo PIM, Jira, Confluence, Bitbucket, GitHub, GitLab, TeamCity, Zabbix, IIS, Nginx Proxy Manager, Windows, Human Task.
Mail & Messaging	Email send/fetch, Slack, Microsoft Teams, Signal, Zoom, Notify.
Core & Utility	Flow composition, Shell, Build, Combine, Binary Decoder, KeePass, No-Op.

Picking an operator and action

A flow step names an operator and an action: invoke: http.get, invoke: mssql.query. The operator is the family; the action is the specific verb within it. Operator names are provider-qualified — zenvara/http, zenvara/postgresql — and the part after the / is the name you use in invoke:.

using:
  - zenvara/postgresql      # import the family

steps:
  - $rows:
      invoke: postgresql.query   # family.action
      on: warehouse
      with:
        Query: "SELECT * FROM orders"

Output field names

Every operator declares descriptive output field names — body, rows, path, content, data, and so on. There is no generic result key. Reference the exact field from the operator’s output schema: ${rows.rows}, ${page.body}, ${file.path}.

Operator kinds

Operators fall into a few kinds that determine how the engine treats them:

• Read operators fetch data; they have no compensating action.
• Write operators mutate external state; each carries a compensating action so a failed flow rolls back its successful writes (saga compensation).
• Compute operators transform data in-process.

The kind is declared in the operator’s definition.yaml and drives retry and rollback behaviour automatically.

Custom operators

When the catalog doesn’t cover a one-off integration, a flow can call a custom Python or PowerShell script as if it were an operator action. Each script lives under scripts/{name}/ with its own definition, language declaration, and entry point; the platform supplies a typed wrapper, captures stdout/stderr to the invocation log, and enforces the same rollback and retry semantics as a built-in operator. See Core & Utility.