wso2 · shanakama · Jun 18, 2026 · Jun 18, 2026 · Jun 22, 2026
diff --git a/en/docs/ai-gateway/README.md b/en/docs/ai-gateway/README.md
@@ -16,18 +16,18 @@ content_type: "overview"
 
 A gateway for managing and securing AI traffic, including Large Language Model (LLM) APIs and Model Context Protocol (MCP) servers.
 
-## Quick Start
+## Quick start
 
 - [LLM Quick Start Guide](llm-proxy/quick-start-guide.md) - Set up the gateway and route traffic to LLM providers like OpenAI
 - [MCP Quick Start Guide](mcp-proxy/quick-start-guide.md) - Set up the gateway and route traffic to MCP servers
 
-## Key Concepts
+## Key concepts
 
-### LLM Provider Template
+### LLM provider template
 
 An LLM Provider Template defines the characteristics and behaviors specific to an AI service provider, such as OpenAI, Azure OpenAI, or other LLM platforms. It describes how the gateway should interpret and extract usage and operational metadata, including prompt, completion, total, and remaining token information, as well as request and response model metadata.
 
-Following templates are shipped out-of-the-box
+The following templates are shipped out-of-the-box:
 
 - OpenAI
 - Azure OpenAI
@@ -36,7 +36,7 @@ Following templates are shipped out-of-the-box
 - Azure AI Foundry
 - Gemini
 
-### LLM Provider
+### LLM provider
 
 An LLM Provider represents a connection to an AI backend service such as OpenAI, Azure OpenAI, or other LLM APIs. Platform administrators configure LLM Providers to define:
 
@@ -49,23 +49,23 @@ An LLM Provider represents a connection to an AI backend service such as OpenAI,
 
 Once configured, the LLM Provider allows traffic to flow through the gateway to the AI backend.
 
-### LLM Proxy
+### LLM proxy
 
-An LLM Proxy allows developers to create custom API endpoints that consume an LLM Provider, while inheriting administrator-enforced access control, budgeting and organization-wide policies defined at the provider level. Each proxy gets its own URL context (e.g., `/assistant`) and can have its own policies applied. This enables:
+An LLM Proxy allows developers to create custom API endpoints that consume an LLM Provider, while inheriting administrator-enforced access control, budgeting, and organization-wide policies defined at the provider level. Each proxy gets its own URL context (e.g., `/assistant`) and can have its own policies applied. This enables:
 
 - Multiple AI applications to share a single LLM Provider
 - Per-application policies such as prompt management and guardrails
 - Separation between platform administration and application development
 
-### MCP Proxy
+### MCP proxy
 
 An MCP Proxy routes Model Context Protocol traffic to MCP servers. MCP is a protocol that enables AI assistants to interact with external tools and data sources. With MCP Proxies, you can:
 
 - Expose MCP servers through a centralized gateway
 - Apply authentication and access control to MCP traffic
 - Manage multiple MCP servers from a single control plane
 
-## Default Ports
+## Default ports
 
 | Port | Service | Description |
 |------|---------|-------------|

diff --git a/en/docs/ai-gateway/ai-gateway-rest-api/authentication.md b/en/docs/ai-gateway/ai-gateway-rest-api/authentication.md
@@ -1,5 +1,5 @@
 ---
-title: "Authentication and Authorization in Gateway Controller"
+title: "Authentication and authorization in Gateway Controller"
 description: "Configure Basic Auth or JWT/IDP authentication and role-based authorization for the AI Gateway Controller REST API."
 canonical_url: https://wso2.com/api-platform/docs/ai-gateway/ai-gateway-rest-api/authentication/
 md_url: https://wso2.com/api-platform/docs/ai-gateway/ai-gateway-rest-api/authentication.md
@@ -12,23 +12,23 @@ last_updated: 2026-06-16
 content_type: "how-to"
 ---
 
-# Authentication & Authorization in Gateway Controller
+# Authentication and authorization in Gateway Controller
 
 ## Overview
 The Gateway Controller REST API (the control-plane API used to manage gateway configuration) can be protected using either locally configured users (Basic Auth) or an external Identity Provider (JWT validation via JWKS). Authorization is role-based and enforced per API route.
 
-## How It Works
+## How it works
 
-### Authentication (Who are you?)
+### Authentication (who are you?)
 You can enable one (or both) of the following:
 
 - **Basic Auth (local users)**: Define usernames/passwords and assign local roles.
-- **IDP/JWT (external users)**: Validate incoming JWTs using `jwks_url` optionally `issuer`.
+- **IDP/JWT (external users)**: Validate incoming JWTs using `jwks_url` and optionally `issuer`.
 
-**No Authentication (open access)**: If BOTH `basic.enabled` and `idp.enabled` are set to `false`, all requests to the gateway controller are allowed without authentication.
+**No Authentication (open access)**: If both `basic.enabled` and `idp.enabled` are set to `false`, all requests to the gateway controller are allowed without authentication.
 
-### Authorization (Are you allowed?)
-Gateway Controller routes are protected using **local roles** (for example `admin`, `developer`, `consumer`).
+### Authorization (are you allowed?)
+Gateway Controller routes are protected using **local roles** (for example, `admin`, `developer`, `consumer`).
 
 - If **`roles_claim` is NOT configured** in the IDP/JWT setup, **authorization is bypassed** for the Gateway Controller REST API routes (i.e., no role checks are performed).
 - If **`roles_claim` IS configured**, you **must** also configure **`role_mapping`**. Without a mapping, the controller cannot translate IDP roles → local roles, and requests will be denied.
@@ -71,7 +71,7 @@ controller:
         consumer: ["*"]
 ```
 
-## Role Mapping Semantics
+## Role mapping semantics
 `role_mapping` is defined as:
 
 ```text
@@ -92,7 +92,7 @@ role_mapping:
 ```
 In this example, a user in `platform-admins` becomes both `admin` and `developer` in the Gateway Controller.
 
-## Troubleshooting (What you’ll observe)
+## Troubleshooting (what you’ll observe)
 - **Requests are denied after enabling JWT auth**: verify `jwks_url` and (if set) `issuer` match the token you're sending.
 - **You enabled `roles_claim` and suddenly everything is forbidden**: add `role_mapping` (mapping is mandatory when `roles_claim` is provided).
 - **Users authenticate but don't have expected access**: confirm the token actually contains the configured `roles_claim`, and that its values match what you listed in `role_mapping`.

diff --git a/en/docs/ai-gateway/analytics/analytics-header-filter.md b/en/docs/ai-gateway/analytics/analytics-header-filter.md
@@ -1,5 +1,5 @@
 ---
-title: "Analytics Header Filter"
+title: "Analytics header filter"
 description: "Control which request and response headers are sent to analytics backends using allow or deny mode in API Platform AI Gateway."
 canonical_url: https://wso2.com/api-platform/docs/ai-gateway/analytics/analytics-header-filter/
 md_url: https://wso2.com/api-platform/docs/ai-gateway/analytics/analytics-header-filter.md
@@ -12,7 +12,7 @@ last_updated: 2026-06-16
 content_type: "reference"
 ---
 
-# Analytics Header Filter
+# Analytics header filter
 
 ## Overview
 
@@ -21,19 +21,19 @@ The Analytics Header Filter policy allows you to control which request and respo
 The policy is only effective when analytics is enabled at the system level and must be explicitly added to the API’s policy chain.
 
 **Operation modes:**
-- **"allow"**: Only the specified headers will be included in analytics (whitelist mode)
-- **"deny"**: All headers except the specified ones will be included in analytics (blacklist mode)
+- **"allow"**: Only the specified headers will be included in analytics (whitelist mode).
+- **"deny"**: All headers except the specified ones will be included in analytics (blacklist mode).
 
 Request and response headers can have different operation modes, allowing for flexible filtering strategies.
 
 
 ## Features
 
-* Filters request and response headers from analytics data collection using allow or deny modes
-* Case-insensitive header matching
-* Supports independent configuration with flexible filtering strategies with whitelist (allow) and blacklist (deny) modes
-* Operates transparently without affecting request or response processing
-* Helps protect sensitive information from being exposed in analytics systems
+* Filters request and response headers from analytics data collection using allow or deny modes.
+* Case-insensitive header matching.
+* Supports independent configuration with flexible filtering strategies with whitelist (allow) and blacklist (deny) modes.
+* Operates transparently without affecting request or response processing.
+* Helps protect sensitive information from being exposed in analytics systems.
 
 
 ## Configuration
@@ -45,7 +45,7 @@ Request and response headers can have different operation modes, allowing for fl
 | `requestHeadersToFilter`  | object | No       | -       | Configuration for filtering request headers. Contains `operation` and `headers` properties.              |
 | `responseHeadersToFilter` | object | No       | -       | Configuration for filtering response headers. Contains `operation` and `headers` properties.              |
 
-### Parameter Structure
+### Parameter structure
 
 Each filter parameter (`requestHeadersToFilter` and `responseHeadersToFilter`) is an object with the following properties:
 
@@ -57,16 +57,16 @@ Each filter parameter (`requestHeadersToFilter` and `responseHeadersToFilter`) i
 > **Note**: This policy only affects analytics data collection. It does not remove or modify headers sent to upstream services or returned to clients.
 
 
-## System Requirements
+## System requirements
 
-* Analytics must be enabled globally via `config.yaml` (`analytics.enabled: true`)
-* The policy must be explicitly applied to the API policy chain
-* If analytics is disabled at the system level, this policy has no effect
+* Analytics must be enabled globally via `config.yaml` (`analytics.enabled: true`).
+* The policy must be explicitly applied to the API policy chain.
+* If analytics is disabled at the system level, this policy has no effect.
 
 
-## API Definition Example
+## API definition example
 
-The following example demonstrates how to apply the Analytics Header Filter policy to a LlmProvider:
+The following example demonstrates how to apply the Analytics Header Filter policy to an `LlmProvider`:
 
 ```bash
 curl -X POST http://localhost:9090/llm-providers \
@@ -112,22 +112,22 @@ spec:
 EOF
 ```
 
-## Use Cases
+## Use cases
 
--  **Sensitive Data Protection**: Prevent authentication tokens, internal identifiers, or security-related headers from being sent to analytics systems.
+- **Sensitive data protection**: Prevent authentication tokens, internal identifiers, or security-related headers from being sent to analytics systems.
 
-- **Noise Reduction**: Exclude verbose or low-value headers to improve the clarity and usefulness of analytics data.
+- **Noise reduction**: Exclude verbose or low-value headers to improve the clarity and usefulness of analytics data.
 
-- **Compliance and Governance**: Support compliance requirements by ensuring certain headers are never exported outside the platform.
+- **Compliance and governance**: Support compliance requirements by ensuring certain headers are never exported outside the platform.
 
-- **Cost and Storage Optimization**: Reduce analytics payload size by removing unnecessary headers from published events.
+- **Cost and storage optimization**: Reduce analytics payload size by removing unnecessary headers from published events.
 
 
 ## Notes
 
 * Header name matching is case-insensitive.
 * The `operation` field is required and must be either `"allow"` or `"deny"`.
-* The `headers` array is required but can be empty. When the array is empty, all original headers are included(if allowed explicitly) in analytics for both `"allow"` and `"deny"` modes (safe fallback behavior).
+* The `headers` array is required but can be empty. When the array is empty, all original headers are included (if allowed explicitly) in analytics for both `"allow"` and `"deny"` modes (safe fallback behavior).
 * Request and response headers can use different operation modes independently.
 * This policy does not block requests or responses.
 * Filtering applies only to analytics collection, not to runtime request handling.

diff --git a/en/docs/ai-gateway/analytics/moesif-analytics.md b/en/docs/ai-gateway/analytics/moesif-analytics.md
@@ -1,5 +1,5 @@
 ---
-title: "Moesif Analytics"
+title: "Moesif analytics"
 description: "Configure Moesif in API Platform AI Gateway to capture and publish API request and response data."
 canonical_url: https://wso2.com/api-platform/docs/ai-gateway/analytics/moesif-analytics/
 md_url: https://wso2.com/api-platform/docs/ai-gateway/analytics/moesif-analytics.md
@@ -33,11 +33,11 @@ This capability allows platform administrators and business stakeholders to gain
 
 ## Prerequisites
 
- - Active Moesif Account and an Application ID
+ - Active Moesif account and an application ID
 > **Note:** For obtaining the Application ID:
 > - Step 1: Sign up in [Moesif](https://www.moesif.com/)
-> - Sept 2: Follow the onboarding wizard.
-> - Sept 3: During the sign up process, you will receive a Collector Application ID for your configured application. Copy this value and keep it saved.
+> - Step 2: Follow the onboarding wizard.
+> - Step 3: During the sign-up process, you will receive a Collector Application ID for your configured application. Copy this value and keep it saved.
 
 > For more detailed instructions and advanced configuration options, refer to the [official Moesif Documentation](https://www.moesif.com/docs).
 
@@ -46,7 +46,7 @@ This capability allows platform administrators and business stakeholders to gain
 
 Analytics is configured entirely through the gateway `config.toml` file and is enabled at a system level.
 
-### System Parameters (`config.toml`)
+### System parameters (`config.toml`)
 
 #### Analytics
 
@@ -58,21 +58,21 @@ Analytics is configured entirely through the gateway `config.toml` file and is e
 
 | Parameter              | Type    | Required | Description                               |
 | ---------------------- | ------- | -------- | ----------------------------------------- |
-| `type`                 | string  | Yes      | Analytics publisher type (Currently limited only to ```moesif``` )                  |
+| `type`                 | string  | Yes      | Analytics publisher type (currently limited only to ```moesif``` )                  |
 | `enabled`              | boolean | Yes      | Enables the publisher                     |
-| `settings`             | object | Yes       | Map of Publisher specific attributes required for configuring the publisher client                     |
+| `settings`             | object | Yes       | Map of publisher-specific attributes required for configuring the publisher client                     |
 
-#### gRPC Event Server
+#### gRPC event server
 
 This section configures both the Envoy access log streaming settings and the ALS (Access Log Service) server that receives those logs. The ALS server runs within the policy-engine component.
 
 | Parameter               | Type     | Required | Default | Description                      |
 | ----------------------- | -------- | -------- |---- | -------------------------------- |
-| `buffer_flush_interval` | duration | No       | `1000000000`| Maximum time Envoy waits(in nanoseconds) before flushing buffered access log entries.|
+| `buffer_flush_interval` | duration | No       | `1000000000`| Maximum time Envoy waits (in nanoseconds) before flushing buffered access log entries.|
 | `buffer_size_bytes`     | int      | No       | `16384` | Maximum size of the in-memory buffer used to batch access log entries before sending them to ALS server.                  |
-| `grpc_request_timeout`  | duration | No       | `20000000000` | Timeout duration Envoy waits(in nanoseconds) for a response from the ALS server before considering the log delivery attempt failed.            |
+| `grpc_request_timeout`  | duration | No       | `20000000000` | Timeout duration Envoy waits (in nanoseconds) for a response from the ALS server before considering the log delivery attempt failed.            |
 | `server_port`           | int     | Yes      | - | gRPC port on which the ALS server listens for incoming access log streams from Envoy.      |
-| `shutdown_timeout`      | int     | No       | `600` | Maximum time allowed for the ALS server to gracefully shut down while completing in-flight log processing(in seconds). |
+| `shutdown_timeout`      | int     | No       | `600` | Maximum time allowed for the ALS server to gracefully shut down while completing in-flight log processing (in seconds). |
 | `als_plain_text`        | boolean | No       | `true` | Use plaintext gRPC        |
 | `public_key_path`       | string | No       | - | Path to the public key used for securing ALS communication when transport-level encryption or authentication is enabled.        |
 | `private_key_path`      | string | No       | - | Path to the private key used for securing ALS communication when transport-level encryption or authentication is enabled.        |
@@ -82,9 +82,9 @@ This section configures both the Envoy access log streaming settings and the ALS
 **Note:** The hostname for the ALS connection is automatically derived from the policy-engine configuration. The internal log name identifier is set to `"envoy_access_log"` and is not configurable.
 
 
-## Configuration Examples
+## Configuration examples
 
-#### Integrate Moesif Publisher
+#### Integrate Moesif publisher
 
 For Moesif analytics integration, the following publisher-specific attributes must be configured under the `settings` section. These parameters control authentication, batching behavior, and publish intervals for efficient analytics delivery. The required attributes are as follows.
 
@@ -124,11 +124,11 @@ max_header_limit = 8192
 ```
 
 
-## Use Cases
+## Use cases
 
-* **API Usage Visibility** – Understand how APIs are consumed across tenants and applications.
-* **Operational Insights** – Observe traffic volume, response behavior, and latency trends.
-* **Business Intelligence** – Support product and business decisions using API analytics data.
-* **Platform Monitoring** – Gain observability into API behavior without impacting performance.
+* **API usage visibility** – Understand how APIs are consumed across tenants and applications.
+* **Operational insights** – Observe traffic volume, response behavior, and latency trends.
+* **Business intelligence** – Support product and business decisions using API analytics data.
+* **Platform monitoring** – Gain observability into API behavior without impacting performance.
 
 
diff --git a/en/docs/ai-gateway/deployment-modes/immutable-gateway.md b/en/docs/ai-gateway/deployment-modes/immutable-gateway.md
@@ -1,5 +1,5 @@
 ---
-title: "Immutable Gateway"
+title: "Immutable gateway"
 description: "Run API Platform AI Gateway in immutable mode, loading LLM and MCP configurations from files at startup for GitOps workflows."
 canonical_url: https://wso2.com/api-platform/docs/ai-gateway/deployment-modes/immutable-gateway/
 md_url: https://wso2.com/api-platform/docs/ai-gateway/deployment-modes/immutable-gateway.md
@@ -12,7 +12,7 @@ last_updated: 2026-06-16
 content_type: "how-to"
 ---
 
-# Immutable Gateway
+# Immutable gateway
 
 This guide explains how to run the API Platform Gateway in **immutable mode**, where API configurations are loaded from files at startup instead of being managed through the REST API.
 
@@ -79,7 +79,7 @@ Artifact files support Go template expressions for injecting dynamic values. Tem
 
 Use `| redact` for sensitive values to hide them from config dumps. A `| default "value"` pipe is available for fallback values. See [Gateway Artifact Templating](../../api-gateway/setup/artifact-templating.md) for the full function reference.
 
-### Sample: Reading List API
+### Sample: Reading list API
 
 Save the following as `artifacts/reading-list-v1.yaml`: