Runtime limits and responsibilities
Understand AI usage, trigger semantics, credentials, provider limits and network access before publishing a Whenever workflow.
Code execution and optional AI
AI writes a workflow; the saved code then runs its rules. That is different from asking an agent to invent a new plan on every execution. It does not make every external result deterministic: provider data can change, and optional AI steps can vary their output.
AI model calls inside a running workflow can incur runtime AI usage. They are separate from the weekly allowance for AI building and editing. See current plans and allowances rather than assuming that a building allowance covers every runtime model call.
An agent loop counts model turns and tool calls against the run's call budget. Put an explicit bound on the loop and validate tool arguments. The AI assistant example shows that pattern; it does not promise an unlimited number of turns.
Schedules, polling and deliveries
A scheduled poll starts a run even if it finds no new items. Webhooks and managed events start executions on qualifying deliveries. One delivery can contain several records or messages; provider delivery behavior and workflow design determine the relationship between messages and runs. There is no universal polling cadence or message-to-run conversion.
Schedules fire at minute granularity, not second granularity, and use the configured timezone. A scheduled run has no delivery body. Keep trigger keys stable, particularly for webhooks: changing a webhook key issues a different URL. See workflow triggers and webhook verification.
Credentials, permissions and provider limits
A listed integration is not a grant of access. Bind the operations your workflow calls, then connect the required account in Setup. HTTP and MCP destinations may require their own credentials, permissions and provider plan. Respect the provider's rate limits, quotas, pagination and payload limits; an execution allowance does not remove those constraints.
Keep non-sensitive settings in ctx.config and stored secrets in ctx.secrets. Do not log or return credential values. Validate external responses and record what a provider actually confirmed rather than reporting a successful outcome merely because a request was sent.
Hosted-runtime reachability
APIs, MCP servers and database endpoints must be reachable from Whenever's hosted runtime. A service reachable only from your laptop, a private network or a local MCP process is not automatically reachable after deployment. Confirm the destination's network access requirements before choosing it for a hosted workflow.
Failures and repeatable work
A step is a recorded boundary, not a resume point. A failed step ends its run. RetryableError records that a failure may be transient and can include a suggested delay; it does not schedule a retry, and a workflow is not automatically replayed.
Make external writes safe to repeat and implement any waiting or duplicate handling your process needs explicitly. Do not repeat an uncertain write without checking the destination's state. Read the steps and error reference for the SDK contract.