diff --git a/daprdocs/content/en/developing-applications/middleware.md b/daprdocs/content/en/developing-applications/middleware.md
index 49b420ecd..955f5655b 100644
--- a/daprdocs/content/en/developing-applications/middleware.md
+++ b/daprdocs/content/en/developing-applications/middleware.md
@@ -5,17 +5,24 @@ linkTitle: "Middleware"
 weight: 50
 description: "Customize processing pipelines by adding middleware components"
 aliases:
-- /developing-applications/middleware/middleware-overview/
-- /concepts/middleware-concept/
+  - /developing-applications/middleware/middleware-overview/
+  - /concepts/middleware-concept/
 ---
 
-Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. A request goes through all defined middleware components before it's routed to user code, and then goes through the defined middleware, in reverse order, before it's returned to the client, as shown in the following diagram.
+Dapr allows custom processing pipelines to be defined by chaining a series of middleware components. There are two places that you can use a middleware pipeline;
+
+1) Building block APIs - HTTP middleware components are executed when invoking any Dapr HTTP APIs.
+2) Service-to-Service invocation - HTTP middleware components are applied to service-to-service invocation calls.
+
+## Configuring API middleware pipelines
+
+When launched, a Dapr sidecar constructs a middleware processing pipeline for incoming HTTP calls. By default, the pipeline consists of [tracing middleware]({{< ref tracing-overview.md >}}) and CORS middleware. Additional middleware, configured by a Dapr [configuration]({{< ref configuration-concept.md >}}), can be added to the pipeline in the order they are defined. The pipeline applies to all Dapr API endpoints, including state, pub/sub, service invocation, bindings, secrets, configuration, distributed lock, and others.
+
+A request goes through all the defined middleware components before it's routed to user code, and then goes through the defined middleware, in reverse order, before it's returned to the client, as shown in the following diagram.
 
 <img src="/images/middleware.png" width=800>
 
-## Configuring middleware pipelines
-
-When launched, a Dapr sidecar constructs a middleware processing pipeline. By default the pipeline consists of [tracing middleware]({{< ref tracing-overview.md >}}) and CORS middleware. Additional middleware, configured by a Dapr [configuration]({{< ref configuration-concept.md >}}), can be added to the pipeline in the order they are defined. The pipeline applies to all Dapr API endpoints, including state, pub/sub, service invocation, bindings, security and others.
+HTTP middleware components are executed when invoking Dapr HTTP APIs using the `httpPipeline` configuration.
 
 The following configuration example defines a custom pipeline that uses a [OAuth 2.0 middleware]({{< ref middleware-oauth2.md >}}) and an [uppercase middleware component]({{< ref middleware-uppercase.md >}}). In this case, all requests are authorized through the OAuth 2.0 protocol, and transformed to uppercase text, before they are forwarded to user code.
 
@@ -28,19 +35,43 @@ metadata:
 spec:
   httpPipeline:
     handlers:
-    - name: oauth2
-      type: middleware.http.oauth2
-    - name: uppercase
-      type: middleware.http.uppercase
+      - name: oauth2
+        type: middleware.http.oauth2
+      - name: uppercase
+        type: middleware.http.uppercase
 ```
 
-As with other building block components, middleware components are extensible and can be found in the [supported Middleware reference]({{< ref supported-middleware >}}) and in the [components-contrib repo](https://github.com/dapr/components-contrib/tree/master/middleware/http).
+As with other components, middleware components can be found in the [supported Middleware reference]({{< ref supported-middleware >}}) and in the [components-contrib repo](https://github.com/dapr/components-contrib/tree/master/middleware/http).
 
 {{< button page="supported-middleware" text="See all middleware components">}}
 
+## Configuring app middleware pipelines
+
+You can also use any middleware components when making service-to-service invocation calls. For example, for token validation in a zero-trust environment, a request transformation for a specific app endpoint, or to apply OAuth policies.
+
+Service-to-service invocation middleware components apply to all outgoing calls from Dapr sidecar to the receiving application (service) as shown in the diagram below.
+
+<img src="/images/app-middleware.png" width=800>
+
+Any middleware component that can be applied to HTTP middleware can also be applied to service-to-service invocation calls as a middleware component using `appHttpPipeline` configuration. The example below adds the `uppercase` middleware component for all outgoing calls from the Dapr sidecar to the application that this configuration is applied to.
+
+```yaml
+apiVersion: dapr.io/v1alpha1
+kind: Configuration
+metadata:
+  name: pipeline
+  namespace: default
+spec:
+  appHttpPipeline:
+    handlers:
+      - name: uppercase
+        type: middleware.http.uppercase
+```
+
+
 ## Writing a custom middleware
 
-Dapr uses [FastHTTP](https://github.com/valyala/fasthttp) to implement its HTTP server. Hence, your HTTP middleware needs to be written as a FastHTTP handler. Your middleware needs to implement a middleware interface, which defines a **GetHandler** method that returns  **fasthttp.RequestHandler** and **error**:
+Dapr uses [FastHTTP](https://github.com/valyala/fasthttp) to implement its HTTP server. Hence, your HTTP middleware needs to be written as a FastHTTP handler. Your middleware needs to implement a middleware interface, which defines a **GetHandler** method that returns **fasthttp.RequestHandler** and **error**:
 
 ```go
 type Middleware interface {
@@ -72,6 +103,7 @@ After the components-contrib change has been accepted, submit another pull reque
 
 ## Related links
 
-* [Component schema]({{< ref component-schema.md >}})
-* [Configuration overview]({{< ref configuration-overview.md >}})
-* [Middleware sample](https://github.com/dapr/samples/tree/master/middleware-oauth-google)
+- [Component schema]({{< ref component-schema.md >}})
+- [Configuration overview]({{< ref configuration-overview.md >}})
+- [API middleware sample](https://github.com/dapr/samples/tree/master/middleware-oauth-google)
+- [App middleware sample](https://github.com/dapr/samples/tree/master/pluggable-components-dotnet-template)
diff --git a/daprdocs/content/en/operations/configuration/configuration-overview.md b/daprdocs/content/en/operations/configuration/configuration-overview.md
index a91878932..dd3e74efc 100644
--- a/daprdocs/content/en/operations/configuration/configuration-overview.md
+++ b/daprdocs/content/en/operations/configuration/configuration-overview.md
@@ -103,10 +103,16 @@ See [metrics documentation]({{< ref "metrics-overview.md" >}}) for more informat
 #### Middleware
 
 Middleware configuration set named HTTP pipeline middleware handlers
-The `httpPipeline` section under the `Configuration` spec contains the following properties:
+The `httpPipeline` and the `appHttpPipeline` section under the `Configuration` spec contains the following properties:
 
 ```yml
-httpPipeline:
+httpPipeline: # for incoming http calls
+  handlers:
+    - name: oauth2
+      type: middleware.http.oauth2
+    - name: uppercase
+      type: middleware.http.uppercase
+appHttpPipeline: # for outgoing http calls
   handlers:
     - name: oauth2
       type: middleware.http.oauth2
diff --git a/daprdocs/content/en/operations/support/support-preview-features.md b/daprdocs/content/en/operations/support/support-preview-features.md
index 2887e6f4a..4e7e8126a 100644
--- a/daprdocs/content/en/operations/support/support-preview-features.md
+++ b/daprdocs/content/en/operations/support/support-preview-features.md
@@ -18,4 +18,4 @@ For CLI there is no explicit opt-in, just the version that this was first made a
 | **--image-registry** flag in Dapr CLI| In self hosted mode you can set this flag to specify any private registry to pull the container images required to install Dapr| N/A | [CLI init command reference]({{<ref "dapr-init.md#self-hosted-environment" >}}) | v1.7 |
 | **Resiliency** | Allows configuring of fine-grained policies for retries, timeouts and circuitbreaking. | `Resiliency` | [Configure Resiliency Policies]({{<ref "resiliency-overview">}}) | v1.7|
 | **Service invocation without default `content-type`** | When enabled removes the default service invocation content-type header value `application/json` when no content-type is provided. This will become the default behavior in release v1.9.0. This requires you to explicitly set content-type headers where required for your apps. | `ServiceInvocation.NoDefaultContentType` | [Service Invocation]({{<ref "service_invocation_api.md#request-contents" >}}) | v1.7 |
-
+| **App Middleware** | Allow middleware components to be executed when making service-to-service calls | N/A | [App Middleware]({{<ref "middleware.md#app-middleware" >}}) | v1.9 |
diff --git a/daprdocs/static/images/app-middleware.png b/daprdocs/static/images/app-middleware.png
new file mode 100644
index 000000000..7e155570b
Binary files /dev/null and b/daprdocs/static/images/app-middleware.png differ