---
schema_version: "1"
id: 5e8a7ae79675a6857b68ff7100388c8ad59fb768c098c02afd3567e5ca70d5b5
title: Disable Outbound Policies
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-gateway/policies-resource-level-disable-outbound.md
canonical_url: https://docs.mulesoft.com/mule-gateway/policies-resource-level-disable-outbound
source_site: docs.mulesoft.com
content_type: documentation
content_hash: a5eb15aa224c671fd3bd21cd4e0961f4beb531f61c22f596ea72dd7991a3f59c
description: MuleSoft Documentation Site
latest: true
---
---
product: Mule Gateway
keywords: policy, outbound-policies, resource-level
---

# Disable Outbound Policies

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

In Mule 4, you can apply policies to both outgoing and incoming HTTP requests.

Policies applied to outgoing HTTP requests are known as outbound policies. You implement them by
defining an `http-policy:operation` block in the policy template, specifying the execution
components.

Mule runtime engine then applies the operation block of every policy that is applied to an API to
every HTTP requester element defined in a Mule application.

In the case of the HTTP proxy, there is only one HTTP Requester defined to which an outbound policy
is applied.

Because Mule applications that implement APIs might invoke several external services, you can define
more than one HTTP Requester for such APIs. In that case, outbound policies are applied to each one
of the HTTP requests that the application performs.

The following example illustrates a Mule application flow implementing an API:

<flow name="implementation">
   <http:listener config-ref="http-config" path="api"/>

<http:request method="GET" url="http://service-1" /> <logger message="#\[payload\]" level="INFO"/>
<http:request method="POST" url="http://service-2" /> </flow>

Every time the Mule application is invoked, two HTTP requests to external services are executed.

In this next example, a Mule policy is applied to the previous example by adding a header to the
HTTP request:

<http-policy:operation> <http-transform:add-request-headers>
<http-transform:headers>#\[{'new-header': 'the-value'}\]</http-transform:headers>
</http-transform:add-request-headers>

<http-policy:execute-next/> </http-policy:operation>

Every time the Mule application is invoked, the Mule policy is executed twice: once when invoking
`service-1` and again when invoking `service-2`. Each HTTP request includes an additional header
called `new-header`, which is added by the policy.

Now imagine a scenario in which `service-1` needs the additional header for authentication, but
`service-2` rejects incoming requests that have unexpected headers.

In Mule 4.3.0, you can meet these requirements by specifying the annotation
`api-gateway:disablePolicies="true"` in any of the Mule application’s HTTP requesters, resulting in
the Mule policy engine not executing policies for that annotated requester.

When using the annotation `api-gateway:disablePolicies="true"`, you must specify the following
namespace in the application:

`xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway"`

As a result, your application flow looks like the following:

<flow name="implementation">
   <http:listener config-ref="http-config" path="api"/>

<http:request method="GET" url="http://service-1" /> <logger message="#\[payload\]" level="INFO"/>
<http:request method="POST" url="http://service-2" api-gateway:disablePolicies="true" /> </flow>

By specifying the annotation on the HTTP requester that invokes `service-2`, the policy is not
applied. Therefore, the additional header is not appended to that particular HTTP request.

If a Mule application with the annotation is deployed to a Mule version prior to 4.3.0, the
annotation has no effect and the policies are not disabled. However, the application is still
deployed.

## See Also

- [Policies for Mule 4](https://docs.mulesoft.com/mule-gateway/policies-included-overview)