docs: update all content to reflect new Workers API

src/content/changelog/workers/2025-08-11-new-workers-api.mdx

@@ -0,0 +1,100 @@
+---
+title: Simpler Workers API that lets you directly manage Workers, Versions, and Deployments
+description: Simpler Workers API, SDK methods, and Terraform resources for directly managing Workers, Versions, and Deployments
+date: 2025-08-11
+---
+
+The current Workers script upload API is convenient for a one-shot Workers deploy. However, it unavoidably creates [Versions and Deployments](/workers/configuration/versions-and-deployments/), and sometimes you don't want that to happen. Sometimes, you want more (and simpler!) control over how and when these are created.
+
+In [Cloudflare Terraform Provider](https://registry.terraform.io/providers/cloudflare/cloudflare/5.9.0/docs) 5.9.0 and [cloudflare-typescript](https://github.com/cloudflare/cloudflare-typescript) 4.6.0 (TODO double check these versions), we're introducing a clean, separated API that makes Workers, Versions, and Deployments individual "capital R" resources with clear concerns. It's now possible to create a Worker entity–and reference it elsewhere–before uploading code, bindings, or making it routable from the internet. You'll also enjoy a more ergonomic way to upload modules, fewer total endpoints, and clearer [API docs](/api/resources/workers/). Check out [Infrastructure as Code (IaC)](/workers/platform/infrastructure-as-code) for detailed examples.
+
+## cloudflare-typescript example
+
+```javascript
+const scriptContent = `
+  export default {
+    async fetch(request, env, ctx) {
+      return new Response(env.MESSAGE, { status: 200 });
+    }
+  };
+`;
+
+/**
+ * Create a Worker and set non-versioned settings like observability
+ */
+const worker = await client.workers.create({
+  "my-worker",
+  account_id: "...",
+  observability: {
+    enabled: true,
+  },
+});
+
+/**
+ * Create the first version of the Worker
+ * This is where code and bindings are defined and can be different between versions
+ */
+const version = await client.workers.versions.create(worker.id, {
+  account_id: "...",
+  main_module: "my-worker-script",
+  compatibility_date: $today,
+  bindings: [ /*...*/ ],
+  modules: [
+    {
+      name: "my-worker-script",
+      content_type: "application/javascript+module",
+      content_base64: Buffer.from(scriptContent).toString("base64"),
+    },
+  ],
+});
+
+/**
+ * Create a deployment and point all traffic to the version we created
+ */
+const deployment = await client.workers.scripts.deployments.create(worker.name, {
+  account_id: "...",
+  strategy: "percentage",
+  versions: [
+    {
+      percentage: 100,
+      version_id: version.id,
+    },
+  ],
+});
+```
+
+## Terraform
+
+In Terraform, you now have the option to just manage the Worker entity. You don't need to manage code, config, or deployments in your plan. This gives you flexibility to use Wrangler for build and deploy—in a different repo—while maintaining presence in your Terraform plan.
+
+```tf
+resource "cloudflare_worker" "my_worker" {
+  account_id = "..."
+  name = "my-important-service"
+}
+
+# Manage Versions and Deployments here or outside of Terraform
+# resource "cloudflare_worker_version" "my_worker_version" {}
+# resource "cloudflare_workers_deployment" "my_worker_deployment" {}
+```
+
+## A radically simpler API
+
+We wanted to make things easier, so we simplified these 8 APIs...
+- /workers/scripts/:script_name
+- /workers/scripts/:script_name/content
+- /workers/scripts/:script_name/script-settings
+- /workers/scripts/:script_name/settings
+- /workers/scripts/:script_name/subdomain
+- /workers/scripts/:script_name/secrets
+- /workers/scripts/:script_name/versions
+- /workers/scripts/:script_name/deployments
+
+Into just three!
+- /workers/workers/:worker_id
+- /workers/workers/:worker_id/versions
+- /workers/scripts/:script_name/deployments
+
+It's not just fewer endpoints... can you guess which of the old APIs created a new Version and Deployment and which didn't? That's no longer a mystery. POST `/versions` creates a Version and POST `/deployments` creates a Deployment.
+
+For now, the new APIs are in beta and the old ones will remain operational. In the future, we plan to mark the old APIs as deprecated in our OpenAPI docs, and remove the old Terraform resources and SDK methods in future major versions.

src/content/docs/workers/configuration/multipart-upload-metadata.mdx

@@ -5,6 +5,11 @@ title: Multipart upload metadata
 
 import { Type, MetaInfo } from "~/components";
 
+:::note
+
+There is a new API for uploading Workers. See [here](/workers/platform/infrastructure-as-code#cloudflare-rest-api) for more information.
+:::
+
 If you're using the [Workers Script Upload API](/api/resources/workers/subresources/scripts/methods/update/) or [Version Upload API](/api/resources/workers/subresources/scripts/subresources/versions/methods/create/) directly, `multipart/form-data` uploads require you to specify a `metadata` part. This metadata defines the Worker's configuration in JSON format, analogue to the [wrangler.toml file](/workers/wrangler/configuration/).
 
 ## Sample `metadata`

src/content/docs/workers/configuration/versions-and-deployments/index.mdx

@@ -69,6 +69,10 @@ When using [Wrangler](/workers/wrangler/), changes made to a Worker's triggers [
 New versions are not created when you make changes to [resources connected to your Worker](/workers/runtime-apis/bindings/). For example, if two Workers (Worker A and Worker B) are connected via a [service binding](/workers/runtime-apis/bindings/service-bindings/), changing the code of Worker B will not create a new version of Worker A. Changing the code of Worker B will only create a new version of Worker B. Changes to the service binding (such as, deleting the binding or updating the [environment](/workers/wrangler/environments/) it points to) on Worker A will also not create a new version of Worker B.
 :::
 
+#### Directly manage Versions and Deployments
+
+See examples of creating a Worker, Versions, and Deployments directly with the API, library SDKs, and Terraform in [Infrastructure as Code](/workers/platform/infrastructure-as-code/).
+
 ### View versions and deployments
 
 #### Via Wrangler

src/content/docs/workers/observability/logs/logpush.mdx

@@ -93,16 +93,6 @@ route = { pattern = "example.org/*", zone_name = "example.org" }
 
 </WranglerConfig>
 
-Configure via multipart script upload API:
-
-```bash
-curl --request PUT \
-"https://api.cloudflare.com/client/v4/accounts/{account_id}/workers/scripts/{script_name}" \
---header "Authorization: Bearer <API_TOKEN>" \
---form 'metadata={"main_module": "my-worker.js", "logpush": true}' \
---form '"my-worker.js"=@./my-worker.js;type=application/javascript+module'
-```
-
 ## Limits
 
 The `logs` and `exceptions` fields have a combined limit of 16,384 characters before fields will start being truncated. Characters are counted in the order of all `exception.name`s, `exception.message`s, and then `log.message`s.