Custom Operators and Workflow Templates

The official Python and Go SDKs currently have no APIs for listing WorkItems, managing custom operators, or working with general workflow templates. They can create a graph, but CatalogWorkflowNode.type is only a string. The SDK does not validate that the target instance has registered that type, nor does it validate ports or initialization parameters.

The built-in document template

The only public high-level workflow template is:

  • Python: SDKClient.create_document_processing_workflow()

  • Go: SDKClient.CreateDocumentProcessingWorkflow()

It creates a fixed read, parse, chunk, embed, and write chain triggered by file load. The current Python source uses EmbeddingNodeV2, while Go uses EmbedNode. This is a real difference between the two main branches; validate each definition against the target instance instead of assuming cross-language identity.

The helper does not accept custom WorkItems, a node list, or arbitrary initialization parameters. For a custom graph, assemble nodes and connections with RawClient.create_workflow()/CreateWorkflow().

Validate a custom graph

Obtain the live WorkItem catalog from the target MOI instance before creation. The current SDKs do not wrap GET /workspaces/:id/workitems, so use an explicitly supported Product API client for that instance or verify the catalog in the UI. Do not maintain a static list of node types.

For every node, confirm:

  • type matches a WorkItem ID or type returned by the target instance;

  • init_parameters follows that WorkItem’s signature and is an empty object, not null, when unused;

  • sender and receiver ports exist;

  • the node version, model, resource, and Catalog objects are available in the workspace.

Create, test, enable, and version custom operators in Catalog or through an API explicitly published by the target instance. CreateWorkflow references a node; it does not register an operator.

For publishing an operator as synchronous HTTP, see the boundary documented in WorkItem API Service.