A workflow’s context is a JavaScript object provided by the serve function and is used to define your workflow endpoint. This context object offers utility methods for creating workflow steps, managing delays, and performing timeout-resistant HTTP calls.
This context object provides utility methods to create workflow steps, wait for certain periods of time or perform timeout-resistant HTTP calls.
Further, the context object provides all request headers, the incoming request payload and current workflow ID.
qstashClient
: QStash client used by the serve method
workflowRunId
: Current workflow run ID
url
: Publically accessible workflow endpoint URL
failureUrl
: URL for workflow failure notifications.
requestPayload
: Incoming request payload
rawInitialPayload
: String version of the initial payload
headers
: Request headers
env
: Environment variables
Defines and executes a workflow step.
Pauses workflow execution for a specified duration.
await
a sleep
action to properly pause execution.Pauses workflow execution until a specific timestamp.
sleepUntil
action to properly pause execution.Performs an HTTP call as a workflow step, allowing for longer response times.
Can take up to 15 minutes or 2 hours, depending on your QStash plans max HTTP connection timeout.
If you want to call OpenAI, you can also use context.api.openai.call
.
If the endpoint you request does not return a success response (status code 200-299),
context.call
will still be treated as successful, and the workflow will continue executing.
As a result, failureFunction
or failureUrl
will not be invoked.
To handle non-success cases, you can check the status
field in the response and implement custom logic as needed.
context.call parameters are:
url
: The URL to send the HTTP request to.method
: The HTTP method to use for the request (e.g., GET, POST, PUT, etc.). Defaults to GET.body
: Body to use in the requestheaders
: An object representing the HTTP headers to include in the request.retries
: The number of retry attempts to make if the request fails. Retries use exponential backoff. Defaults to 0 (no retries).flowControl
: To limit the number of calls made to your endpoint. See Flow Control for more details. The default is no limit.
key
: The key to use for flow control.rate
: The maximum number of calls per second.parallelism
: The maximum number of calls that can be active at the same time.period
: Time window over which the rate limit is enforced.timeout
: The maximum duration to wait for a response from the endpoint, in seconds. If retries are enabled, this timeout applies individually to each retry attempt.workflow
: If you are using serveMany
, you can call another workflow defined under the same serveMany
method by passing it to the workflow
parameter of context.call
.context.call attempts to parse the response body as JSON. If this is not possible, the body is returned as it is.
In TypeScript, you can declare the expected result type as follows:
The context.call method can make requests to any public API endpoint. However, it cannot:
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
In addition to context.call, another way to make third party requests is to use the context.api namespace. Under this namespace, you can find integrations for OpenAI, Anthropic and Resend.
With context.api, you can call the available integrations in a typesafe manner.
We are planning to add more integrations over time.
You can learn more about these integrations under the integrations section.
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
Stops the workflow run until it is notified externally to continue.
There is also a timeout setting which makes the workflow continue if it’s not notified within the time frame.
Default timeout value is 7 days.
A workflow run waiting for event can be notified in two ways:
context.notify
: Notify step explained belowclient.notify
: Notify method of the Workflow Client.This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
Notifies workflows waiting for an event with some payload.
notifyResponse
is a list of NotifyResponse
objects:
More details about the Waiter
object:
Triggers another workflow run and waits for its completion.
The workflow continues when the invoked workflow finishes, whether successfully, with failure, or is canceled.
The body
is the data returned by the invoked workflow, if any is returned.
Only workflows that served together can invoke each other. To learn more about how you can serve multiple workflows together, checkout Invoke other workflows guide.
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
The methods we listed so far were all for defining a workflow step. context.cancel
is different.
context.cancel
allows you to cancel the current workflow:
retries
option.A workflow’s context is a JavaScript object provided by the serve function and is used to define your workflow endpoint. This context object offers utility methods for creating workflow steps, managing delays, and performing timeout-resistant HTTP calls.
This context object provides utility methods to create workflow steps, wait for certain periods of time or perform timeout-resistant HTTP calls.
Further, the context object provides all request headers, the incoming request payload and current workflow ID.
qstashClient
: QStash client used by the serve method
workflowRunId
: Current workflow run ID
url
: Publically accessible workflow endpoint URL
failureUrl
: URL for workflow failure notifications.
requestPayload
: Incoming request payload
rawInitialPayload
: String version of the initial payload
headers
: Request headers
env
: Environment variables
Defines and executes a workflow step.
Pauses workflow execution for a specified duration.
await
a sleep
action to properly pause execution.Pauses workflow execution until a specific timestamp.
sleepUntil
action to properly pause execution.Performs an HTTP call as a workflow step, allowing for longer response times.
Can take up to 15 minutes or 2 hours, depending on your QStash plans max HTTP connection timeout.
If you want to call OpenAI, you can also use context.api.openai.call
.
If the endpoint you request does not return a success response (status code 200-299),
context.call
will still be treated as successful, and the workflow will continue executing.
As a result, failureFunction
or failureUrl
will not be invoked.
To handle non-success cases, you can check the status
field in the response and implement custom logic as needed.
context.call parameters are:
url
: The URL to send the HTTP request to.method
: The HTTP method to use for the request (e.g., GET, POST, PUT, etc.). Defaults to GET.body
: Body to use in the requestheaders
: An object representing the HTTP headers to include in the request.retries
: The number of retry attempts to make if the request fails. Retries use exponential backoff. Defaults to 0 (no retries).flowControl
: To limit the number of calls made to your endpoint. See Flow Control for more details. The default is no limit.
key
: The key to use for flow control.rate
: The maximum number of calls per second.parallelism
: The maximum number of calls that can be active at the same time.period
: Time window over which the rate limit is enforced.timeout
: The maximum duration to wait for a response from the endpoint, in seconds. If retries are enabled, this timeout applies individually to each retry attempt.workflow
: If you are using serveMany
, you can call another workflow defined under the same serveMany
method by passing it to the workflow
parameter of context.call
.context.call attempts to parse the response body as JSON. If this is not possible, the body is returned as it is.
In TypeScript, you can declare the expected result type as follows:
The context.call method can make requests to any public API endpoint. However, it cannot:
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
In addition to context.call, another way to make third party requests is to use the context.api namespace. Under this namespace, you can find integrations for OpenAI, Anthropic and Resend.
With context.api, you can call the available integrations in a typesafe manner.
We are planning to add more integrations over time.
You can learn more about these integrations under the integrations section.
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
Stops the workflow run until it is notified externally to continue.
There is also a timeout setting which makes the workflow continue if it’s not notified within the time frame.
Default timeout value is 7 days.
A workflow run waiting for event can be notified in two ways:
context.notify
: Notify step explained belowclient.notify
: Notify method of the Workflow Client.This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
Notifies workflows waiting for an event with some payload.
notifyResponse
is a list of NotifyResponse
objects:
More details about the Waiter
object:
Triggers another workflow run and waits for its completion.
The workflow continues when the invoked workflow finishes, whether successfully, with failure, or is canceled.
The body
is the data returned by the invoked workflow, if any is returned.
Only workflows that served together can invoke each other. To learn more about how you can serve multiple workflows together, checkout Invoke other workflows guide.
This feature is not yet available in workflow-py. See our Roadmap for feature parity plans and Changelog for updates.
The methods we listed so far were all for defining a workflow step. context.cancel
is different.
context.cancel
allows you to cancel the current workflow:
retries
option.