[moonia33]

What

Adds an optional saveResponseAs setting to the WEBHOOK workflow step. When set, the parsed JSON body of a successful (2xx) response is stored in the execution context under that key, so later steps can use it like trigger event data, e.g. {{event.coupon.code}} in a SEND_EMAIL template, a CONDITION, or another WEBHOOK.

Why

Workflows often need a value that only an external system can produce at run time, for example a unique one-time coupon code created by the shop right before an abandoned-cart email. Today the webhook response is only stored in the step output and is not available to later steps.

How

• WorkflowStepConfigSchemas.webhook: new optional saveResponseAs (letters, digits, underscores, max 64 chars, not starting with a digit; id, email, data, event, unsubscribeUrl, subscribeUrl, manageUrl are rejected).
• executeWebhook: on a 2xx response of at most 64 KB, merges {[saveResponseAs]: parsedResponse} into workflowExecution.context (one update, no new query patterns). Non-2xx or oversized responses are not saved. The step output gets savedAs (key or null) when the option is used.
• Webhook step dialog: "Save response as (optional)" input.
• Docs: guides/webhooks.mdx (new section) and the step table in concepts/workflows.mdx.

Existing webhook steps are unaffected (no saveResponseAs → no context change, step output unchanged).

Tests

WorkflowExecutionService.webhook.test.ts: saves the response into the context, a later webhook renders {{event.coupon.code}}, nothing saved on 5xx, no change without the option, reserved/invalid names rejected.

[Copilot]

Note

Copilot was unable to complete this review at the selected tier due to model policy or plan restrictions.

🟡 Changes recommended

The change still has unresolved issues because the Webhook step dialog’s saveResponseAs validation and messaging don’t match backend constraints (including reserved names), and the accompanying docs omit an enforced naming rule, leaving users prone to confusing submission failures.

2 open issues

• saveResponseAs client validation misses reserved names and has wrong error · New
• Docs omit the no-leading-digit rule for saveResponseAs · New

What changed in this PR

Adds an optional saveResponseAs setting to WEBHOOK workflow steps so successful webhook JSON responses can be stored in the workflow execution context and referenced by later steps via the existing {{event.*}} templating.

Changes:

• Extend the webhook step config schema with validated saveResponseAs (including reserved-name protection).
• Update webhook execution to persist bounded (≤64 KB), 2xx responses into execution context and surface savedAs in step output when configured.
• Add UI support, documentation updates, and tests covering the new behavior and validation.

File	Description
packages/​shared/​src/​schemas/​index.ts	Adds an optional, validated saveResponseAs field to the webhook step schema with constraints and reserved-name checks.
apps/​wiki/​content/​docs/​guides/​webhooks.mdx	Documents how to save a webhook response into context and reference it in later workflow steps.
apps/​wiki/​content/​docs/​concepts/​workflows.mdx	Updates the workflows documentation to include saveResponseAs as an optional configuration for WEBHOOK steps.
apps/​web/​src/​components/​workflow-steps/​WebhookStepDialog.tsx	Adds a dialog input for configuring saveResponseAs on webhook steps and includes it in step updates.
apps/​api/​src/​services/​WorkflowExecutionService.ts	Implements saving successful, size-bounded webhook responses into the workflow execution context and reports savedAs in the step output.
apps/​api/​src/​services/​__tests__/​WorkflowExecutionService.webhook.test.ts	Adds test coverage for saving webhook responses into context, downstream templating usage, and invalid/reserved name handling.

_{Review effort: Balanced}