diff --git a/src/content/changelog/fundamentals/2025-03-21-resource-force-replacement-bug.mdx b/src/content/changelog/fundamentals/2025-03-21-resource-force-replacement-bug.mdx
new file mode 100644
index 00000000000000..8f8a4cd6fc380c
--- /dev/null
+++ b/src/content/changelog/fundamentals/2025-03-21-resource-force-replacement-bug.mdx
@@ -0,0 +1,29 @@
+---
+title: Dozens of Cloudflare Terraform Provider resources now have proper drift detection
+description: Improper drift detection in the Cloudflare Terraform Provider resulted in dozens of resources always indicating they needed to be updated or replaced.
+products:
+  - fundamentals
+date: 2025-03-21T00:00:00Z
+---
+
+In [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, dozens of resources now have proper drift detection. Before this fix, these resources would indicate they needed to be updated or replaced — even if there was no real change. Now, you can rely on your `terraform plan` to only show what resources are expected to change. 
+
+This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features:
+
+- API Shield
+- Argo Smart Routing
+- Argo Tiered Caching
+- Bot Management
+- BYOIP
+- D1
+- DNS
+- Email Routing
+- Hyperdrive
+- Observatory
+- Pages
+- R2
+- Rules
+- SSL/TLS
+- Waiting Room
+- Workers
+- Zero Trust
diff --git a/src/content/changelog/fundamentals/2025-03-21-sensitive-values-redacted.mdx b/src/content/changelog/fundamentals/2025-03-21-sensitive-values-redacted.mdx
new file mode 100644
index 00000000000000..3b05a126441b11
--- /dev/null
+++ b/src/content/changelog/fundamentals/2025-03-21-sensitive-values-redacted.mdx
@@ -0,0 +1,23 @@
+---
+title: Cloudflare Terraform Provider now properly redacts sensitive values
+description: Resources in the Cloudflare Terraform Provider that have sensitive properties will not show those values in logs.
+products:
+  - fundamentals
+date: 2025-03-21T00:00:00Z
+---
+
+In the [Cloudflare Terraform Provider](https://github.com/cloudflare/terraform-provider-cloudflare) versions 5.2.0 and above, sensitive properties of resources are redacted in logs. Sensitive properties in [Cloudflare's OpenAPI Schema](https://raw.githubusercontent.com/cloudflare/api-schemas/refs/heads/main/openapi.yaml) are now annotated with `x-sensitive: true`. This results in proper auto-generation of the corresponding Terraform resources, and prevents sensitive values from being shown when you run Terraform commands.
+
+This issue affected [resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) related to these products and features:
+
+- Alerts and Audit Logs
+- Device API
+- DLP
+- DNS
+- Magic Visibility
+- Magic WAN
+- TLS Certs and Hostnames
+- Tunnels
+- Turnstile
+- Workers
+- Zaraz
diff --git a/src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx b/src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx
new file mode 100644
index 00000000000000..8653d647dd990c
--- /dev/null
+++ b/src/content/changelog/workers/2025-03-22-smart-placement-stablization.mdx
@@ -0,0 +1,14 @@
+---
+title: Smart Placement is smarter about running Workers and Pages Functions in the best locations
+description: Workers and Pages Functions with Smart Placement enabled will not unexpectedly return to default locations if request traffic dips.
+products:
+  - workers
+  - pages
+date: 2025-03-22T00:00:00Z
+---
+
+[Smart Placement](/workers/configuration/smart-placement/) is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.
+
+Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one.
+
+Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case.
diff --git a/src/content/changelog/workers/2025-04-15-workers-api-fixes.mdx b/src/content/changelog/workers/2025-04-15-workers-api-fixes.mdx
new file mode 100644
index 00000000000000..2b38b8f507ba8a
--- /dev/null
+++ b/src/content/changelog/workers/2025-04-15-workers-api-fixes.mdx
@@ -0,0 +1,60 @@
+---
+title: Fixed and documented Workers Routes and Secrets API
+description: The Workers Routes API now returns a correct response and the Secrets API has been added to the Cloudflare API docs.
+products:
+  - workers
+  - workers-for-platforms
+date: 2025-04-15T00:00:00Z
+---
+
+## Workers Routes API
+
+Previously, a request to the Workers [Create Route API](/api/resources/workers/subresources/routes/methods/create/) always returned `null` for "script" and an empty string for "pattern" even if the request was successful.
+
+```bash title="Example request"
+curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \
+-X PUT \
+-H "Authorization: Bearer $CF_API_TOKEN" \
+-H 'Content-Type: application/json' \
+--data '{ "pattern": "example.com/*", "script": "hello-world-script" }'
+```
+
+```json title="Example bad response"
+{
+	"result": {
+		"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
+		"pattern": "",
+		"script": null,
+		"request_limit_fail_open": false
+	},
+	"success": true,
+	"errors": [],
+	"messages": []
+}
+```
+
+Now, it properly returns all values!
+
+```json title="Example good response"
+{
+	"result": {
+		"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
+		"pattern": "example.com/*",
+		"script": "hello-world-script",
+		"request_limit_fail_open": false
+	},
+	"success": true,
+	"errors": [],
+	"messages": []
+}
+```
+
+## Workers Secrets API
+
+The [Workers](/api/resources/workers/subresources/scripts/subresources/secrets/) and [Workers for Platforms](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/subresources/secrets/) secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as [cloudflare-typescript](https://github.com/cloudflare/cloudflare-typescript) (>4.2.0) and [cloudflare-python](https://github.com/cloudflare/cloudflare-python) (>4.1.0).
+
+Note the `cloudflare_workers_secret` and `cloudflare_workers_for_platforms_script_secret` [Terraform resources](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs) are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:
+
+- [Secrets Store](/api/resources/secrets_store/) with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
+- "Secret Text" Binding on [Workers Script Upload](/api/resources/workers/subresources/scripts/methods/update/) and [Workers for Platforms Script Upload](/api/resources/workers_for_platforms/subresources/dispatch/subresources/namespaces/subresources/scripts/methods/update/)
+- Workers (and WFP) Secrets API