Deploy a workflow

Move an automation into Whenever: prepare the workflow module, bind integrations, complete Setup and publish the intended triggers.

Start from your coding tool

Use the copyable deployment prompt in the tool where you wrote the automation. It points the agent to Whenever's authoring guide. Connect the tool to the Whenever MCP server so it can work with the workflow and its workspace bindings, not only generate a file.

The authoring target is a TypeScript module using @wix/whenever-workflow-sdk: an exported manifest, named steps and a default defineWorkflow export. The agent can check the module against the real build and save it as a draft. A draft is not a substitute for completing Setup and publishing.

Prepare the module

Declare at least one trigger in the manifest and give each trigger a stable, unique key. Choose a schedule, webhook, managed event or manual trigger to match the process.
Put calls to external services in named steps. Validate unknown response bodies and return provider-confirmed receipts rather than a claim of success.
Read non-sensitive settings from ctx.config and stored secrets from ctx.secrets, not environment variables. The names your source uses determine the values requested in Setup.
Bind each provider operation used by the workflow. Workspace bindings supply the generated integration types; a method name copied from another workspace is not sufficient.
Take runtime time and randomness from ctx.now() and ctx.random(). See the module example and steps reference.

Complete Setup and publish

The coding agent hands the owner a Setup link for values and connections the code needs. Supply the config values and secrets, authorize the required products and review the account and permissions each connection grants. A provider's plan, limits and network requirements still apply.

For a signed webhook, use the sender-specific helper and its Setup connection rather than treating a plain webhook() as authenticated. Keep the trigger key fixed so edits do not unexpectedly replace its URL. Review which event types can reach external writes.

Review the workflow's intended behavior before publishing: what starts it, what it reads and what it changes. Check each trigger path using representative input and inspect the resulting run history. Publishing a schedule or webhook makes its automatic behavior consequential; do not use production writes as a harmless connectivity probe.

Troubleshoot a blocked deployment

An integration method is missing

Check that the operation is bound in this workspace. The built-in ports are AI, HTTP, MCP and Postgres; other provider methods depend on workspace bindings. After binding, use the generated signature rather than guessing parameters.

Setup is incomplete or access is denied

Check every config and secret name the source declares, the connected account, the provider permissions and any required provider plan. Keep secrets in Setup, never in the workflow source or diagnostic output.

A URL works locally but not when hosted

Check reachability from the hosted runtime. Localhost and private-network-only endpoints do not become public because a workflow calls them. Confirm the destination's network policy and authentication requirements.

A scheduled run has no input

That is the schedule contract: it supplies no delivery body. Read settings from config and branch on ctx.trigger when the same module also handles webhook or event deliveries.

A run fails after a provider call

Inspect the failing step and the provider's response before repeating a write. A RetryableError is failure metadata, not an automatic retry. Build any delay and duplicate handling your process needs into the workflow explicitly.