Workers API
This guide details the Workflows API within Cloudflare Workers, including methods, types, and usage examples.
The WorkflowEntrypoint
class is the core element of a Workflow definition. A Workflow must extend this class and define a run
method with at least one step
call to be considered a valid Workflow.
-
run(event: WorkflowEvent<T>, step: WorkflowStep): Promise<T>
event
- the event passed to the Workflow, including an optionalpayload
containing data (parameters)step
- theWorkflowStep
type that provides the step methods for your Workflow
The WorkflowEvent
type accepts an optional type parameter ↗ that allows you to provide a type for the payload
property within the WorkflowEvent
.
Refer to the events and parameters documentation for how to handle events within yur Workflow code.
-
The
WorkflowEvent
is the first argument to a Workflow'srun
method, and includes an optionalpayload
parameter and atimestamp
property.payload
- a default type ofany
or typeT
if a type parameter is provided.timestamp
- aDate
object set to the time the Workflow instance was created (triggered).
Refer to the events and parameters documentation for how to handle events within yur Workflow code.
-
step.do(name: string, callback: (): RpcSerializable): Promise<T>
-
step.do(name: string, config?: WorkflowStepConfig, callback: (): RpcSerializable): Promise<T>
name
- the name of the step.config
(optional) - an optionalWorkflowStepConfig
for configuring step specific retry behaviour.callback
- an asynchronous function that optionally returns serializable state for the Workflow to persist.
-
step.sleep(name: string, duration: WorkflowDuration): Promise<void>
name
- the name of the step.duration
- the duration to sleep until, in either seconds or as aWorkflowDuration
compatible string.- Refer to the documentation on sleeping and retrying to learn more about how how Workflows are retried.
-
step.sleepUntil(name: string, timestamp: Date | number): Promise<void>
name
- the name of the step.timestamp
- a JavaScriptDate
object or seconds from the Unix epoch to sleep the Workflow instance until.
- A
WorkflowStepConfig
is an optional argument to thedo
method of aWorkflowStep
and defines properties that allow you to configure the retry behaviour of that step.
Refer to the documentation on sleeping and retrying to learn more about how how Workflows are retried.
-
throw new NonRetryableError(message: string , name string optional)
: NonRetryableError- Throws an error that forces the current Workflow instance to fail and not be retried.
- Refer to the documentation on sleeping and retrying to learn more about how how Workflows are retried.
Workflows exposes an API directly to your Workers scripts via the bindings concept. Bindings allow you to securely call a Workflow without having to manage API keys or clients.
You can bind to a Workflow by defining a [[workflows]]
binding within your wrangler.toml
configuration.
For example, to bind to a Workflow called workflows-starter
and to make it available on the MY_WORKFLOW
variable to your Worker script, you would configure the following fields within the [[workflows]]
binding definition:
You can also bind to a Workflow that is defined in a different Worker script from the script your Workflow definition is in. To do this, provide the script_name
key with the name of the script to the [[workflows]]
binding definition in your wrangler.toml
configuration.
For example, if your Workflow is defined in a Worker script named billing-worker
, but you are calling it from your web-api-worker
script, your wrangler.toml
would resemble the following:
The Workflow
type provides methods that allow you to create, inspect the status, and manage running Workflow instances from within a Worker script.
The Workflow
type exports the following methods:
Create (trigger) a new instance of the given Workflow.
-
create(options?: WorkflowInstanceCreateOptions): Promise<WorkflowInstance>
options
- optional properties to pass when creating an instance, includng a user-provided ID and payload parameters.
An ID is automatically generated, but a user-provided ID can be specified (up to 64 characters 1). This can be useful when mapping Workflows to users, merchants or other identifiers in your system. You can also provide a JSON object as the params
property, allowing you to pass data for the Workflow instance to act on as its WorkflowEvent
.
Returns a WorkflowInstance
.
You can also provide a type parameter to the Workflows
type when creating (triggering) a Workflow instance using the create
method of the Workers API. Note that this does not propagate type information into the Workflow itself, as TypeScript types are a build-time construct. To provide the type of an incoming WorkflowEvent
, refer to the TypeScript and type parameters section of the Workflows documentation.
To provide an optional type parameter to the Workflow
, pass a type argument with your type when defining your Workflow bindings:
Get a specific Workflow instance by ID.
-
get(id: string): Promise<WorkflowInstance>
id
- the ID of the Workflow instance.
Returns a WorkflowInstance
. Throws an exception if the instance ID does not exist.
Optional properties to pass when creating an instance.
Represents a specific instance of a Workflow, and provides methods to manage the instance.
Return the id of a Workflow.
-
id: string
Return the status of a running Workflow instance.
-
status(): Promise<void>
Pause a running Workflow instance.
-
pause(): Promise<void>
Restart a Workflow instance.
-
restart(): Promise<void>
Terminate a Workflow instance.
-
terminate(): Promise<void>
Details the status of a Workflow instance.
-
Match pattern:
^[a-zA-Z0-9_][a-zA-Z0-9-_]*$
↩