Mule Gateway Overview | MuleSoft Documentation
# Mule Gateway Overview
Mule runtime engine includes an embedded Mule Gateway. Mule Gateway enables you to add a dedicated orchestration layer on top of your backend APIs and services to help you separate orchestration from implementation. You can leverage the governance capabilities of API Manager to apply, among other capabilities, throttling, security, caching, and logging to your APIs.
For example, using Mule Gateway you can:
  * Apply a basic authentication policy on top of a Mule application.
  * Enrich an incoming or outgoing message.
  * Add any other complex capability to an API without having to write any code.


If you want to apply policies and generate analytics info, you must use either:
  * An API defined in a Mule application.
  * A Mule application that proxies your existing backend implementation.


## Key Concepts
An API is an abstraction of a set of components. It encapsulates the complexity of your Mule application development, and it presents an easy and reusable way of accessing your assets.
Pairing your API to API Manager through an Autodiscovery element enables you to apply policies to that API.
Learn more About API Autodiscovery.
#### HTTP/HTTPS API
An API that you create using an HTTP Exchange asset. Mule Gateway assumes that the associated Mule application being tracked by API Manager has an HTTP or HTTPS listener defined as an implementation endpoint.
**Typical usage** : REST based APIs.
See Creating an API Asset.
#### RAML API
An API that you create using a RAML/OAS Exchange asset. Your Mule Gateway assumes that the associated Mule application being tracked by API Manager has an HTTP or HTTPS listener with a RAML/OAS router defined as an implementation endpoint.
To make this asset available in Exchange, you can design your API using API Designer and then export it to Exchange.
**Typical usage** : RAML/OAS based APIs.
See Create and Publish an API Specification with the Code Editor in Design Center.
#### WSDL API
An API that you create using a WSDL Exchange asset. Your Mule Gateway assumes that the associated Mule application being tracked by API Manager has an HTTP or HTTPS listener with a WSDL router defined as an implementation endpoint.
**Typical usage** : WSDL based APIs.
### API Autodiscovery
API Autodiscovery enables API Manager to manage an API that represents an HTTP endpoint of a Mule application.
Essentially, it’s the mechanism that links an HTTP resource to its API definition in API Manager.
Through API Autodiscovery, Mule Gateway syncs the configuration defined in the corresponding paired API from API Manager. Mule runtime requires Anypoint Platform organization credentials to use Autodiscovery.
See the API Autodiscovery article for more information.
### API Proxy
API proxies, also known as "autogenerated proxies", enhance the usability of API Manager in your Mule application.
**Typical usage** : Either when you want to leverage Mule Gateway capabilities and your backend API is not based on Mule Runtime, or when your API is based on Mule runtime but you are unable to define the corresponding Autodiscovery element because it is a closed code.
When you configure your API to be a Proxy Endpoint, Anypoint Platform enables you to download a preconfigured Mule application. If the application is deployed to Mule runtime and you use the correct Anypoint Platform credentials, API Manager automatically tracks the API.
You can deploy the application to a correctly configured Mule runtime, without knowing the details of how to create a Mule application.
Anypoint Platform can deploy the proxy directly to Cloudhub or using the Mule agent, through Runtime Manager.   
---  
If you would like to use HTTPS instead of HTTP, you can follow these steps:
  1. Import the autogenerated proxy into Anypoint Studio.
  2. Specify the certificates to be used.
  3. Deploy the application to Cloudhub or a runtime instance.


The proxies that can be downloaded from API Platform are a convenient tool to speed up your Application Network development. However, you’re not restricted to using these autogenerated proxies. You can use any Mule application, with correctly configured Autodiscovery, to leverage Mule Gateway capabilities.
### Policies
Policies are the tool to apply orthogonal behavior to a whole API or to a resource of it.
You can create policies to enrich, filter, and control Incoming/Outgoing messages, and to apply a security layer on top of your API by, for example, enforcing token access to your API or whitelisting/blacklisting specific IP addresses.
Mule Gateway provides not only Out-Of-The-Box (OOTB) policies but an engine to create your own Custom Policies.
### Analytics
When the Mule Gateway is connected to API Manager, you can monitor the usage of your registered API using **API Analytics**.
Mule Gateway reports API usage, including the detected policy violations.
#### Pointcut
Mule Gateway uses pointcuts to point a policy to the resource where it should be applied.
If you are enforcing a policy in API Manager, this policy uses pointcuts to determine the endpoints of your Mule application to which it should apply.
Just as the API autodiscovery element must be declared in your Mule application code, pointcuts are declared within the policies.
In Mule 4, pointcuts are invisible to the user and are only managed internally by the Mule Gateway and API Manager.
You can select the granularity of the pointcut when configuring most policies. You can find this configuration under the **Method & Resource conditions** of your policies.
The two available options are:
  * **Apply configurations to all API methods & resources**.
When selected, the API Pointcut matches every resource and method of your API. This means that the policy being applied will be executed for every request the HTTP Listener (linked with the API via Autodiscovery) receives.
  * **Apply configurations to specific methods & resources**.
This defines a resource-level pointcut for your API. In this example, the policy is applied to the API only when the request method is a GET. You can optionally define a matching regex for the resource for further granularity.


## Enabling Mule Gateway capabilities
To take advantage of Mule Gateway capabilities, establish a communication channel between Mule runtime and an organization created in a control plane (US or EU) or Mule Private Cloud Edition.
To configure Mule runtime in such a way, you must specify your Anypoint organization credentials.
Depending on your implementation, there are several ways to pass organization credentials to the runtime.
See Configuring Organization Credentials in Mule Runtime 4 or Mule Runtime 3 to learn how to do this.
## Mule Gateway on Hyperforce
All features of Mule Gateway are supported on Hyperforce. However, some API Manager Hyperforce limitations affect Mule Gateway. To learn more, see API Manager on Hyperforce.
### Mule Gateway Proxies on Hyperforce
All Mule Gateway proxies are supported on Hyperforce. See this table to find the first proxy versions that are supported on Hyperforce:
HTTP and HTTPS proxy  
---  
REST Proxy | 2.2.1 and 3.2.1  
WSDL Proxy | 2.2.1 and 3.1.1  
### Mule Gateway Policies on Hyperforce
All Mule Gateway policies are supported on Hyperforce. See this table to find the first policy definition and implementation versions that are supported on Hyperforce:
Policy | Definition | Implementation  
---|---|---  
Basic Authentication: LDAP  
Basic Authentication: Simple  
Client ID Enforcement  
Cross-Origin Resource Sharing (CORS)  
Header Injection  
Header Removal  
HTTP Caching  
IP Allowlist  
IP Blocklist  
JSON Threat Protection  
JWT Validation  
Message Logging  
OAuth 2.0 Access Token Enforcement Using Mule OAuth Provider  
OpenAM OAuth 2.0 Token Enforcement  
OpenID Connect OAuth 2.0 Access Token Enforcement  
PingFederate OAuth 2.0 Token Enforcement  
Rate Limiting  
Rate Limiting: SLA-based  
Spike Control  
XML Threat Protection  
## See Also
  * Reviewing Mule Gateway API Autodiscovery concepts