Renaming Workers API to Workflows API for Workflow APIs

Author: Oxyjun

public/__redirects

@@ -1936,6 +1936,7 @@
 # workflows
 /workflows/reference/storage-options/ /workers/platform/storage-options/ 301
 /workflows/tutorials/ /workflows/examples 301
+/workflows/build/workers-api/ /workflows/build/workflows-api/ 301
 
 # workers KV
 /kv/platform/environments/ /kv/reference/environments/ 301

src/content/changelog/workflows/2024-10-24-workflows-beta.mdx

@@ -23,6 +23,6 @@ npm create cloudflare@latest workflows-starter -- --template "cloudflare/workflo
 
 You can open the `src/index.ts` file, extend it, and use `wrangler deploy` to deploy your first Workflow. From there, you can:
 
-- Learn the [Workflows API](/workflows/build/workers-api/)
+- Learn the [Workflows API](/workflows/build/workflows-api/)
 - [Trigger Workflows](/workflows/build/trigger-workflows/) via your Workers apps.
 - Understand the [Rules of Workflows](/workflows/build/rules-of-workflows/) and how to adopt best practices

src/content/changelog/workflows/2025-01-15-workflows-more-steps.mdx

@@ -6,12 +6,12 @@ products:
 date: 2025-01-15
 ---
 
-[Workflows](/workflows/) (beta) now allows you to define up to 1024 [steps](/workflows/build/workers-api/#workflowstep). `sleep` steps do not count against this limit.
+[Workflows](/workflows/) (beta) now allows you to define up to 1024 [steps](/workflows/build/workflows-api/#workflowstep). `sleep` steps do not count against this limit.
 
 We've also added:
 
-* `instanceId` as property to the [`WorkflowEvent`](/workflows/build/workers-api/#workflowevent) type, allowing you to retrieve the current instance ID from within a running Workflow instance
+* `instanceId` as property to the [`WorkflowEvent`](/workflows/build/workflows-api/#workflowevent) type, allowing you to retrieve the current instance ID from within a running Workflow instance
 * Improved queueing logic for Workflow instances beyond the current maximum concurrent instances, reducing the cases where instances are stuck in the queued state.
-* Support for [`pause` and `resume`](/workflows/build/workers-api/#pause) for Workflow instances in a queued state.
+* Support for [`pause` and `resume`](/workflows/build/workflows-api/#pause) for Workflow instances in a queued state.
 
 We're continuing to work on increases to the number of concurrent Workflow instances, steps, and support for a new `waitForEvent` API over the coming weeks.

src/content/changelog/workflows/2025-04-07-workflows-ga.mdx

@@ -42,7 +42,7 @@ export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {
 
 </TypeScriptExample>
 
-You can then send a Workflow an event from an external service via HTTP or from within a Worker using the [Workers API](/workflows/build/workers-api/) for Workflows:
+You can then send a Workflow an event from an external service via HTTP or from within a Worker using the [Workers API](/workflows/build/workflows-api/) for Workflows:
 
 <TypeScriptExample>
 

src/content/docs/agents/api-reference/run-workflows.mdx

@@ -105,4 +105,4 @@ You can also call a Workflow that is defined in a different Workers script from
 
 </WranglerConfig>
 
-Refer to the [cross-script calls](/workflows/build/workers-api/#cross-script-calls) section of the Workflows documentation for more examples.
+Refer to the [cross-script calls](/workflows/build/workflows-api/#cross-script-calls) section of the Workflows documentation for more examples.

src/content/docs/workers/configuration/cron-triggers.mdx

@@ -15,7 +15,7 @@ Cron Triggers are ideal for running periodic jobs, such as for maintenance or ca
 
 :::note
 
-Cron Triggers can also be combined with [Workflows](/workflows/) to trigger multi-step, long-running tasks. You can [bind to a Workflow](/workflows/build/workers-api/) from directly from your Cron Trigger to execute a Workflow on a schedule.
+Cron Triggers can also be combined with [Workflows](/workflows/) to trigger multi-step, long-running tasks. You can [bind to a Workflow](/workflows/build/workflows-api/) from directly from your Cron Trigger to execute a Workflow on a schedule.
 
 :::
 

src/content/docs/workflows/build/call-workflows-from-pages.mdx

@@ -37,7 +37,7 @@ services = [
 
 Your Worker can expose a specific method (or methods) that only other Workers or Pages Functions can call over the Service Binding.
 
-In the following example, we expose a specific `createInstance` method that accepts our `Payload` and returns the [`InstanceStatus`](/workflows/build/workers-api/#instancestatus) from the Workflows API:
+In the following example, we expose a specific `createInstance` method that accepts our `Payload` and returns the [`InstanceStatus`](/workflows/build/workflows-api/#instancestatus) from the Workflows API:
 
 <TypeScriptExample filename="index.ts">
 ```ts
@@ -97,7 +97,7 @@ Service Bindings don't require you to expose a public endpoint from your Worker,
 
 :::
 
-An alternative to setting up a Service Binding is to call the Worker over HTTP by using the Workflows [Workers API](/workflows/build/workers-api/#workflow) to `create` a new Workflow instance for each incoming HTTP call to the Worker:
+An alternative to setting up a Service Binding is to call the Worker over HTTP by using the Workflows [Workers API](/workflows/build/workflows-api/#workflow) to `create` a new Workflow instance for each incoming HTTP call to the Worker:
 
 <TypeScriptExample filename="index.ts">
 ```ts
@@ -137,6 +137,6 @@ You can also choose to authenticate these requests by passing a shared secret in
 
 ### Next steps
 
-* Learn more about how to programatically call and trigger Workflows from the [Workers API](/workflows/build/workers-api/)
+* Learn more about how to programatically call and trigger Workflows from the [Workers API](/workflows/build/workflows-api/)
 * Understand how to send [events and parameters](/workflows/build/events-and-parameters/) when triggering a Workflow
 * Review the [Rules of Workflows](/workflows/build/rules-of-workflows/) and best practices for writing Workflows

src/content/docs/workflows/build/events-and-parameters.mdx

@@ -67,7 +67,7 @@ npx wrangler@latest workflows trigger workflows-starter '{"some":"data"}'
 
 A running Workflow can wait for an event (or events) by calling `step.waitForEvent` within the Workflow, which allows you to send events to the Workflow in one of two ways:
 
-1. Via the [Workers API binding](/workflows/build/workers-api/): call `instance.sendEvent` to send events to specific workflow instances.
+1. Via the [Workers API binding](/workflows/build/workflows-api/): call `instance.sendEvent` to send events to specific workflow instances.
 2. Using the REST API (HTTP API)'s [Events endpoint](/api/resources/workflows/subresources/instances/subresources/events/methods/create/).
 
 Because `waitForEvent` is part of the `WorkflowStep` API, you can call it multiple times within a Workflow, and use control flow to conditionally wait for an event.

src/content/docs/workflows/build/rules-of-workflows.mdx

@@ -380,7 +380,7 @@ export class MyWorkflow extends WorkflowEntrypoint {
 
 ### Instance IDs are unique
 
-Workflow [instance IDs](/workflows/build/workers-api/#workflowinstance) are unique per Workflow. The ID is the unique identifier that associates logs, metrics, state and status of a run to a specific instance, even after completion. Allowing ID re-use would make it hard to understand if a Workflow instance ID referred to an instance that run yesterday, last week or today.
+Workflow [instance IDs](/workflows/build/workflows-api/#workflowinstance) are unique per Workflow. The ID is the unique identifier that associates logs, metrics, state and status of a run to a specific instance, even after completion. Allowing ID re-use would make it hard to understand if a Workflow instance ID referred to an instance that run yesterday, last week or today.
 
 It would also present a problem if you wanted to run multiple different Workflow instances with different [input parameters](/workflows/build/events-and-parameters/) for the same user ID, as you would immediately need to determine a new ID mapping.
 
@@ -452,7 +452,7 @@ export class MyWorkflow extends WorkflowEntrypoint {
 
 ### Batch multiple Workflow invocations
 
-When creating multiple Workflow instances, use the [`createBatch`](/workflows/build/workers-api/#createBatch) method to batch the invocations together. This allows you to create multiple Workflow instances in a single request, which will reduce the number of requests made to the Workflows API and increase the number of instances you can create per minute.
+When creating multiple Workflow instances, use the [`createBatch`](/workflows/build/workflows-api/#createBatch) method to batch the invocations together. This allows you to create multiple Workflow instances in a single request, which will reduce the number of requests made to the Workflows API and increase the number of instances you can create per minute.
 
 <TypeScriptExample filename="index.ts">
 

src/content/docs/workflows/build/workers-api.mdx renamed to src/content/docs/workflows/build/workflows-api.mdx

@@ -1,5 +1,5 @@
 ---
-title: Workers API
+title: Workflows API
 pcx_content_type: concept
 sidebar:
   order: 2
@@ -29,7 +29,7 @@ export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {
   * `event` - the event passed to the Workflow, including an optional `payload` containing data (parameters)
   * `step` - the `WorkflowStep` type that provides the step methods for your Workflow
 
-The `run` method can optionally return data, which is available when querying the instance status via the [Workers API](/workflows/build/workers-api/#instancestatus), [REST API](/api/resources/workflows/subresources/instances/subresources/status/) and the Workflows dashboard. This can be useful if your Workflow is computing a result, returning the key to data stored in object storage, or generating some kind of identifier you need to act on.
+The `run` method can optionally return data, which is available when querying the instance status via the [Workers API](/workflows/build/workflows-api/#instancestatus), [REST API](/api/resources/workflows/subresources/instances/subresources/status/) and the Workflows dashboard. This can be useful if your Workflow is computing a result, returning the key to data stored in object storage, or generating some kind of identifier you need to act on.
 
 ```ts
 export class MyWorkflow extends WorkflowEntrypoint<Env, Params> {