Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts, line 413:

<comment>Use proper validation instead of `as` type casting for request body data. The codebase already uses zod schemas for request validation (see `transferWorkflow` handler). Consider defining a zod schema to validate `inputData` and `pinData` types from the request body, rather than using type assertions on untrusted input.</comment>

<file context>
@@ -379,6 +381,51 @@ export = {
+				// Execute workflow
+				const executionService = Container.get(WorkflowExecutionService);
+				const result = await executionService.executeViaPublicApi(workflow, req.user, {
+					inputData: inputData as IDataObject | undefined,
+					pinData: pinData as IPinData | undefined,
+				});
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/workflows/workflow-execution.service.ts, line 280:

<comment>The new `executeViaPublicApi` method and its helper `findStartNode` lack unit tests despite containing meaningful business logic (start node preference logic, inputData→pinData conversion, error handling). The existing test file tests similar methods extensively. Consider adding tests for:
- Finding manual trigger when present
- Falling back to other triggers
- Error when no trigger exists
- inputData to pinData conversion
- Direct pinData passthrough</comment>

<file context>
@@ -272,6 +273,67 @@ export class WorkflowExecutionService {
+	 * Execute a workflow via the public API.
+	 * Returns the execution ID immediately (asynchronous execution).
+	 */
+	async executeViaPublicApi(
+		workflow: WorkflowEntity,
+		user: User,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/public-api/v1/handlers/workflows/spec/paths/workflows.id.execute.yml, line 15:

<comment>Response schema should mark `executionId` as required for proper OpenAPI documentation and client code generation. This matches the codebase pattern (e.g., `error.yml`, `user.yml`).</comment>

<file context>
@@ -0,0 +1,40 @@
+    required: false
+    content:
+      application/json:
+        schema:
+          type: object
+          properties:
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts, line 424:

<comment>Type narrowing with `as` keyword. The Zod schema produces `Record&lt;string, unknown&gt; | undefined`, which is then cast to `IDataObject | undefined`. Consider defining a type-safe Zod schema that produces the correct type, or use a type guard. Alternatively, if `IDataObject` is compatible with `Record&lt;string, unknown&gt;`, update `executeViaPublicApi` to accept the Zod-inferred type directly.</comment>

<file context>
@@ -379,6 +381,62 @@ export = {
+				// Execute workflow
+				const executionService = Container.get(WorkflowExecutionService);
+				const result = await executionService.executeViaPublicApi(workflow, req.user, {
+					inputData: inputData as IDataObject | undefined,
+					pinData: pinData as IPinData | undefined,
+				});
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/public-api/v1/handlers/workflows/workflows.handler.ts, line 425:

<comment>Type narrowing with `as` keyword. The Zod schema produces a complex record type, which is then cast to `IPinData | undefined`. Consider defining a type-safe Zod schema that produces the correct type, or use a type guard. Alternatively, if `IPinData` is compatible with the Zod-inferred type, update `executeViaPublicApi` to accept it directly.</comment>

<file context>
@@ -379,6 +381,62 @@ export = {
+				const executionService = Container.get(WorkflowExecutionService);
+				const result = await executionService.executeViaPublicApi(workflow, req.user, {
+					inputData: inputData as IDataObject | undefined,
+					pinData: pinData as IPinData | undefined,
+				});
+
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/workflows/workflow-execution.service.ts, line 307:

<comment>Using `as IDataObject` for type narrowing violates the type casting rule. Consider using a type guard function to validate `inputData`, or keep the `IDataObject` type in the function signature if the API layer already ensures the correct type.</comment>

<file context>
@@ -296,11 +299,12 @@ export class WorkflowExecutionService {
 			// Convert simple inputData to pinData format for the start node
 			effectivePinData = {
-				[startNode.name]: [{ json: inputData }],
+				[startNode.name]: [{ json: inputData as IDataObject }],
 			};
 		}
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At packages/cli/src/workflows/workflow-execution.service.ts, line 303:

<comment>Using `as IPinData` for type narrowing violates the type casting rule. Consider using a type guard function to validate the `pinData` structure, or keep the `IPinData` type in the function signature if the API layer already validates this structure.</comment>

<file context>
@@ -296,11 +299,12 @@ export class WorkflowExecutionService {
 			// Use provided pinData directly (advanced mode)
-			effectivePinData = pinData;
+			// The pinData structure from the API is compatible with IPinData
+			effectivePinData = pinData as IPinData;
 		} else if (inputData) {
 			// Convert simple inputData to pinData format for the start node
</file context>