Disable Outbound Policies | MuleSoft Documentation
# Disable Outbound Policies
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
  *