diff --git a/docs/upgrade/feature-availability/api-features.mdx b/docs/upgrade/feature-availability/api-features.mdx
index b2619d434..cc5233265 100644
--- a/docs/upgrade/feature-availability/api-features.mdx
+++ b/docs/upgrade/feature-availability/api-features.mdx
@@ -201,9 +201,9 @@ In Hasura v2, federation was possible using a number of different methods, inclu
 instances, creating an API gateway, or instituting a multi-protocol approach.
 
 **In Hasura DDN, federation is fully supported** — just like CI/CD, it's built into the core of the product. We use the
-concept of [subgraphs](/collaboration/best-practices.mdx) to allow you to create a unified API across
-independent teams and services, ensuring that each subgraph can be developed and deployed independently while still
-being part of a larger, cohesive API.
+concept of [subgraphs](/collaboration/best-practices.mdx) to allow you to create a unified API across independent teams
+and services, ensuring that each subgraph can be developed and deployed independently while still being part of a
+larger, cohesive API.
 
 ### Apollo Federation
 
@@ -223,8 +223,7 @@ In Hasura v2, API limits were available to help manage and control the usage of
 In Hasura v2, allow lists were available to restrict access to specific queries and mutations. This feature was useful
 for controlling access to sensitive data or operations.
 
-**In Hasura DDN, allow lists are currently a work in progress (WIP)**, with plans to introduce more advanced
-authorization mechanisms, allowing for more granular control over your API.
+**In Hasura DDN, allow lists can be generated using [Engine Plugins](/plugins/overview.mdx)**.
 
 ### Permissions