[Radar] Deprecate layer 7 attack magnitude parameter

Author: andre-j3sus

src/content/docs/radar/investigate/application-layer-attacks.mdx

@@ -17,7 +17,7 @@ Since we are examining attacks, we can inspect both sides of an attack — both
 
 This ability to filter by both sides of the attack is only available in the `top locations` endpoints. Unless otherwise specified, other endpoints are filtered by source location, like the origin location of the attack.
 
-The magnitude of the attack is defined by the total number of mitigated requests, unless otherwise specified.
+The magnitude of the attack is defined by the total number of mitigated requests.
 
 Like in [HTTP requests](/radar/investigate/http-requests), these endpoints can be split into the ability to fetch a timeseries, a single value summarizing the entire date range, and a list of top locations.
 
@@ -167,10 +167,8 @@ For more information refer to [Get layer 7 top target locations](/api/resources/
 
 Which source-target location pairs constitute the biggest attacks in the last 24 hours?
 
-How big an attack is, or the attack magnitude, can be defined by the number of mitigated requests (the default) or by the number of total zones under attack.
-
 ```bash
-curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/top/attacks?limit=5&dateRange=1d&magnitude=MITIGATED_REQUESTS&format=json" \
+curl "https://api.cloudflare.com/client/v4/radar/attacks/layer7/top/attacks?limit=5&dateRange=1d&format=json" \
 --header "Authorization: Bearer <API_TOKEN>"
 ```
 
@@ -232,8 +230,6 @@ A typical response will be similar to the following:
 
 This means that 3.79% of all mitigated requests are from and to the US, 3.6% of all mitigated requests are from the US to Belgium, etc..
 
-This response came from a query that is using attack `magnitude` as the sum of mitigated requests. To use the number of unique zones attacked as the metric, for example, use `attack_magnitude=AFFECTED_ZONES`.
-
 For more information refer to [Get layer 7 top attack pairs](/api/resources/radar/subresources/attacks/subresources/layer7/subresources/top/methods/attacks/).
 
 ## Next steps

src/content/release-notes/api-deprecations.yaml

@@ -5,6 +5,24 @@ productLink: "/fundamentals/"
 productArea: Core platform
 productAreaLink: /fundamentals/reference/changelog/platform/
 entries:
+  - publish_date: "2025-03-11"
+    title: "Cloudflare Radar: Layer 7 attack magnitude parameter"
+    description: |-
+      Deprecation date: March 11, 2025
+
+      End of life date: June 11, 2025
+
+      The layer 7 attack `magnitude` query parameter, which allows defining attack magnitude by total requests mitigated (`MITIGATED_REQUESTS`) or total zones attacked (`AFFECTED_ZONES`), is deprecated.
+      Moving forward, Cloudflare Radar will only support defining layer 7 attack magnitude based on the total number of mitigated requests.
+
+      Affected API:
+
+      `GET /radar/attacks/layer7/top/attacks`
+
+      Replacement:
+
+      Users should stop using the `magnitude` parameter, as the default behavior already uses `MITIGATED_REQUESTS`.
+
   - publish_date: "2025-07-01"
     title: Cloudflare DWeb Resolver
     description: |-
@@ -191,27 +209,27 @@ entries:
 
       The following URL parameters for filtering DNS records are deprecated:
 
-      - `name=contains:value`  
+      - `name=contains:value`
         Instead, use the supported `name.contains=value` syntax.
-      - `name=starts_with:value`  
+      - `name=starts_with:value`
         Instead, use the supported `name.startswith=value` syntax.
-      - `name=ends_with:value`  
+      - `name=ends_with:value`
         Instead, use the supported `name.endswith=value` syntax.
-      - `name=one,two,three` (searching for one of multiple possible names, separated by commas)  
+      - `name=one,two,three` (searching for one of multiple possible names, separated by commas)
         Instead, make multiple requests, one for each possible `name`.
         Alternatively, if only querying the `name` field, the `?match=any&name=one&name=two&name=three` syntax can be used instead.
         This syntax has an extended deprecation date of May 23, 2025.
-      - `content=contains:value`  
+      - `content=contains:value`
         Instead, use the supported `content.contains=value` syntax.
-      - `content=starts_with:value`  
+      - `content=starts_with:value`
         Instead, use the supported `content.startswith=value` syntax.
-      - `content=ends_with:value`  
+      - `content=ends_with:value`
         Instead, use the supported `content.endswith=value` syntax.
-      - `content=one,two,three` (searching for one of multiple possible contents, separated by commas)  
+      - `content=one,two,three` (searching for one of multiple possible contents, separated by commas)
         Instead, make multiple requests, one for each possible `content`.
         Alternatively, if only querying the `content` field, the `?match=any&content=one&content=two&content=three` syntax can be used instead.
         This syntax has an extended deprecation date of May 23, 2025.
-      - `type=contains:value`  
+      - `type=contains:value`
         Searching for substrings of a type name will no longer be supported.
         Instead, please search for an exact type name, such as `type=CNAME`.
         If the input value is a free-text search from a human user, consider using the `search` parameter instead.