```mdx
Quick Summary
This release restructures the entire Cloudflare Workers Observability API surface, replacing seven unscoped root-level paths with account-scoped equivalents under the /accounts/{account_id}/workers/observability/ prefix. All seven removals happened without a formal deprecation period, meaning any integration currently calling /destinations, /destinations/{slug}, /telemetry/keys, /telemetry/query, or /telemetry/values is already broken. The new endpoints mirror the old functionality but are now properly namespaced, which aligns Workers Observability with how the rest of the Cloudflare API handles multi-tenant account isolation. Teams should treat this as an urgent migration rather than a routine upgrade.
---
Editor's Note: We see this as a meaningful architectural correction rather than a routine patch — Cloudflare is bringing Workers Observability in line with the account-scoped conventions used across their broader API, and the abrupt removal suggests these root-level paths may have been provisional from the start. The pattern mirrors similar namespace migrations we've tracked across other Cloudflare product APIs over the past year. Our practical tip: audit your HTTP client base URLs and any hardcoded path constants before anything else, since the prefix change affects every single endpoint in this surface.
---
Changes by Severity
#### 🔴 Immediate Action Required
/destinations removed (×2) — Both operations on this root-level path have been dropped without deprecation. Any code constructing requests to /destinations will receive errors immediately./destinations/{slug} removed (×2) — The slug-parameterized variant is equally gone. Clients that read or mutate a specific destination by slug need to update the path prefix before the next request./telemetry/keys removed — Telemetry key enumeration is no longer available at the root path. Dashboards or scripts that poll this endpoint to discover available keys will silently fail or surface HTTP errors./telemetry/query removed — This is likely the highest-traffic endpoint in the group; any automated telemetry query pipeline calling the old path is now non-functional./telemetry/values removed — Value lookups for telemetry fields are also gone from the root namespace.#### 🟢 Informational
/accounts/{account_id}/workers/observability/destinations added (×2) — Replaces the removed /destinations operations. The {account_id} segment is now required in every request./accounts/{account_id}/workers/observability/destinations/{slug} added (×2) — Direct replacement for /destinations/{slug}, with the account scope prepended./accounts/{account_id}/workers/observability/telemetry/keys added — Replaces /telemetry/keys; functionally equivalent but scoped to a specific account./accounts/{account_id}/workers/observability/telemetry/query added — Replaces /telemetry/query with the new account-namespaced path./accounts/{account_id}/workers/observability/telemetry/values added — Replaces /telemetry/values; same scoping requirement applies.---
Migration Playbook
1. Identify your account ID. Every new endpoint requires {account_id} as a path parameter. Retrieve this from the Cloudflare dashboard under Account Home → Settings, or via the /accounts API endpoint. Store it as an environment variable (e.g., CF_ACCOUNT_ID) rather than hardcoding it.
```bash
export CF_ACCOUNT_ID="your_account_id_here"
```
2. Audit all hardcoded base paths. Search your codebase for references to the old root-level paths. The following patterns should be flagged:
```bash
grep -rn '"/destinations"' .
grep -rn '"/telemetry/' .
grep -rn "'/destinations" .
grep -rn "'/telemetry/" .
```
3. Update your base URL or path constants. Replace each old path with its account-scoped equivalent. If you use a centralized API client or constants file, update it there first to avoid partial migrations.
```diff
- const DESTINATIONS_PATH = "/destinations";
+ const DESTINATIONS_PATH = /accounts/${CF_ACCOUNT_ID}/workers/observability/destinations;
- const TELEMETRY_QUERY_PATH = "/telemetry/query";
+ const TELEMETRY_QUERY_PATH = /accounts/${CF_ACCOUNT_ID}/workers/observability/telemetry/query;
- const TELEMETRY_KEYS_PATH = "/telemetry/keys";
+ const TELEMETRY_KEYS_PATH = /accounts/${CF_ACCOUNT_ID}/workers/observability/telemetry/keys;
- const TELEMETRY_VALUES_PATH = "/telemetry/values";
+ const TELEMETRY_VALUES_PATH = /accounts/${CF_ACCOUNT_ID}/workers/observability/telemetry/values;
```
4. Update slug-parameterized destination calls. For any code that references a specific destination by its {slug}, apply the same prefix change:
```diff
- fetch(/destinations/${slug})
+ fetch(/accounts/${CF_ACCOUNT_ID}/workers/observability/destinations/${slug})
```
5. Verify authentication headers still apply. The new paths sit under the standard account-scoped namespace, so your existing Authorization: Bearer or API key headers should carry over — but confirm that your token has the appropriate Workers Observability permissions scoped to the target account.
```bash
curl -X GET \
"https://api.cloudflare.com/client/v4/accounts/${CF_ACCOUNT_ID}/workers/observability/destinations" \
-H "Authorization: Bearer ${CF_API_TOKEN}"
```
6. Update any CI/CD pipeline environment variables or secrets that reference the old paths. This includes integration test fixtures, mock server configurations, and any OpenAPI-generated client code that may have been generated from the previous schema version.
7. Regenerate any SDK or client code derived from the Cloudflare OpenAPI spec. If your team auto-generates a typed client from the schema, pull the latest spec from commit 91391624b5fe and regenerate before deploying updated application code.
8. Test each endpoint independently in a staging environment before promoting to production. Prioritize /telemetry/query given its likely role in any real-time observability pipeline, then validate /destinations CRUD operations, and finally confirm /telemetry/keys and /telemetry/values return expected data shapes.
---
Verification Checklist
CF_ACCOUNT_ID (or equivalent) is set in all deployment environments and accessible to the application at runtime/destinations or /destinations/{slug} exist in application code, configuration files, or test fixtures/telemetry/keys, /telemetry/query, or /telemetry/values (root-level) exist anywhere in the codebase/accounts/{account_id}/workers/observability/destinations returns a 2xx response in the target environment/accounts/{account_id}/workers/observability/telemetry/query returns expected telemetry data/accounts/{account_id}/workers/observability/destinations/{slug} resolve correctly for at least one known slug91391624b5fe---
References
```