# mulesoft API Manager - Full Documentation --- product: API Manager version: 2.x is-latest-version: true --- # Access Asset and Developer Portals > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Open a managed API from API Manager into Anypoint Exchange to browse the private asset portal for that version when you have Portals Viewer access or the portal appears on the public developer catalog. You can also start in Exchange under Public portal and select an asset from the organization’s catalog. Administrators review resources, methods, publish dates, and mocking from the same Exchange experience in either path, and they manage sharing and public portal visibility from Anypoint Exchange. ## Open a Private Asset Portal from API Manager Before you open an asset portal, confirm you meet at least one requirement: - The portal is listed in the organization’s public developer portal. - The portal is private, but you have Portals Viewer access. To open an asset portal: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance that you want to access. 3. Click **Actions** and select **View API in Exchange**. The portal for the selected asset opens in Exchange. You can share the asset and [make the portal public](https://docs.mulesoft.com/exchange/about-portals) from Anypoint Exchange. ## Open the Organization’s Public Portal in Exchange To open an organization’s public portal: 1. Navigate to **Exchange** > **Public portal**. 2. From the developer portal page, select the asset that you want to access. ## See Also - [About Portals in Exchange](https://docs.mulesoft.com/exchange/about-portals) - [Anypoint Platform developer portal](https://dev-portal.mulesoft.com/index.html?filter=api) --- product: API Manager version: 2.x is-latest-version: true --- # Add API Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - [Adding a Mule Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) Use Mule Gateway if you have APIs on Mule Runtime that need an API gateway to manage, observe, and secure your APIs. - [Adding an Omni Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-flex) Use Omni Gateway for any APIs that need a flexible and performant API gateway that works with distributed and microservices environments and fits into your CI/CD environments. - [Adding an Omni Gateway Agent or Tool Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-agent-tool) Use Omni Gateway for any agent, broker, LLM, or MCP server that needs a flexible and performant gateway that works with distributed and microservices environments and fits into your CI/CD environments. - [Adding an MCP Bridge Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mcp-bridge) Use Omni Gateway MCP Bridge to create MCP servers to expose your current API instances as MCP tools so agents can discover and call them. - [Adding an MCP Server from Public Exchange](https://docs.mulesoft.com/api-manager/latest/create-instance-public-exchange) Use Public Exchange to add an MCP Server from a public exchange asset. --- product: API Manager version: 2.x is-latest-version: true --- # Add Instance Alerts in API Manager (Mule Gateway) > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Instance alerts in API Manager email recipients when request volume, response codes, response times, or other conditions cross thresholds you set for an API instance on Mule Gateway. You name each alert, set severity, choose from [alert types](https://docs.mulesoft.com/api-manager/latest/using-api-alerts), configure time ranges as sliding windows, and specify email recipients. Policy Violation alerts are unavailable for [automated policies](https://docs.mulesoft.com/gateway/latest/policies-automated-overview), and Omni Gateway instances use [a separate alert workflow](https://docs.mulesoft.com/gateway/latest/use-api-alerts). > [!NOTE] This task applies to Mule Gateway runtimes only. To add alerts to instances that use Omni > Gateway as their runtime, see > [Using Omni Gateway API Alerts](https://docs.mulesoft.com/gateway/latest/use-api-alerts). ## Configure an Instance Alert To add an alert to a Mule Gateway instance: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the instance to which to add an alert. 3. Click **Alerts** > **Add alert**. 4. Specify the alert options: - **Name**: Type an alert name, for example `trial-alert`. If adding multiple alerts to the same environment, the alerts must have unique names. - **Enabled**: The default option is **Enabled**. You can delete an alert anytime if not required. - **Severity**: Select a severity for the alert, for example, **Info**. - **Alert type**: Select the type of alert to create, (for example, **Request Count**) and provide appropriate alert configuration values. For information about alert types, see [Instance Alerts](https://docs.mulesoft.com/api-manager/latest/using-api-alerts#api-alerts). > [!TIP] In the **For at least** and **consecutive period(s) of** fields, enter a value in the > range of 1 - 999999999 to specify the time interval as a > [sliding window](https://www.techopedia.com/definition/869/sliding-window). 5. Select **Recipients**. Specify which email addresses receive the email notification. The first recipient appears in the email **To** field, and the remaining recipients appear in the **CC** field. 6. Click **Create Alert**. ## See Also - [Review Alerts Concepts](https://docs.mulesoft.com/api-manager/latest/using-api-alerts) - [Using Omni Gateway API Alerts](https://docs.mulesoft.com/gateway/latest/use-api-alerts) --- product: API Manager version: 2.x is-latest-version: true --- # Add SLA Tiers for Anypoint DataGraph > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Add multiple SLA tiers to an Anypoint DataGraph instance to control user access and limit requests. To add an SLA tier: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **DataGraph Administration** > **SLA Tiers**: 3. From the DataGraph SLA Tiers page, click **Add SLA tier**: ![The illustration shows the Add SLA tier window](/mulesoft/current/en-us/api-manager/latest/_images/datagraph-add-sla-tier.png) 4. In the **\# of Reqs** field, add the number of requests a client can make, for example, `100`. 5. In the **Time Period** field, specify a timeout before a client request fails, for example, `60`. 6. In the **Time Unit** field, select the unit of time from the drop-down list, for example, `Seconds`. 7. If you want to display the SLA tier with the contract, select **Visible** . 8. If you want to create additional SLA tiers, click **Add Limit**. 9. Click **Add**. ## See Also - [Anypoint DataGraph Overview](https://docs.mulesoft.com/datagraph/) - [Reviewing SLA Tiers Concepts on API Manager](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers) --- product: API Manager version: 2.x is-latest-version: true --- # Add SLA Tiers to API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can add multiple SLA tiers to an API Group instance. To add an SLA tier: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. Expand the **API Group** list and click the API Group instance to which you want to add the SLA tier. 4. Click **SLA Tiers** and then click **Add SLA tier** on the details page. 5. Enter a name for the SLA tier, for example `Premium`. 6. Optionally add a description. 7. Select either **Manual** or **Automatic** for **Approval** method. 8. Click **Continue**. 9. At the top of the SLA tier details page, click the **Default** tab if you want the SLA tier to apply to API instances in the API Group instance. Otherwise, click **Individual** to apply it to a specific API instance within the API Group instance. > [!NOTE] You can copy an SLA tier of an API instance when creating an individual limit for that > API instance in the API Group instance. You can modify the copied limit, if required: 10. In the **\# of Reqs** field, add the number of request that are allowed, for example, `100`. 11. In the **Time Period** field, specify the amount of time, for example, `60`. 12. In the **Time Unit** field, select the unit of time from the drop-down list, for example, `Second`. 13. If you want to display the SLA tier with the contract, select the **Visible** check box. 14. If you want to create additional SLA tiers, click **Add new limit**. 15. Click **Save**. ## See Also - [Remove SLA Tiers from API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-remove-sla-tier) - [Manage Group Instance Contracts](https://docs.mulesoft.com/api-manager/latest/api-groups-manage-api-group-instance-contracts) --- product: API Manager version: 2.x is-latest-version: true --- # Adding a Mule Gateway API Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you have created an API using Design Center or any other application, you can then manage that API in API Manager by adding an API instance. API instances remain under management until you delete them. Use Mule Gateway if you have APIs on Mule Runtime that need an API gateway to manage, observe, and secure your APIs. There are three options for adding an API instance: - [**Add a new API:**](#add-api) Select this option to add a completely new instance of an API. - [**Promote API from environment:**](#promote-api) Select this option if you have an API instance in a different environment, for instance the sandbox environment, and you want to promote it to the current or production environment. - [**Import API from zip file:**](#import-api) Select this option if you have exported an API instance from a different Anypoint Platform instance. When you are promoting or importing an API instance, you do not have options to alter the configuration. However, when you add a new API instance, you need to the downstream and the upstream configuration settings. The following diagram shows the relationship of the upstream and downstream configurations settings to your upstream service and the downstream consumer application. In this configuration, the downstream service is the service making API requests that are completed by the upstream service. These terms represent the direction of dependency, not the direction of information. A downstream service could make a `POST` request where it provides information to the upstream service. However, the downstream service is still dependent on the upstream service to complete the request. ![The API instance is deployed on a gateway between the upstream and downstream configuration](/mulesoft/current/en-us/api-manager/latest/_images/api-upstream-downstream-config.png) ## Add a New API 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add** and select **Add new API**. 3. Select **Mule Gateway**. 4. Select the **Proxy type** from the following options: Connect to existing application (basic endpoint) Use this option to directly interact with a Mule runtime Engine (Mule) application when your application is configured with API gateway autodiscovery. See [API Autodiscovery](https://docs.mulesoft.com/mule-gateway/mule-gateway-autodiscovery-overview) for more information. Select the **Mule version**. Deploy a proxy application Use this option to interact by proxy with an application, either because it is a Mule application not configured with API gateway autodiscovery or because it is not a Mule application. See [Configure Proxies for your APIs](https://docs.mulesoft.com/api-manager/latest/api-proxy-landing-page) for more information. 5. If you selected to deploy a proxy application, select the **Target type** from the following options: - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores by default. 1. Select a space. To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. 1. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 2. Enter a **Proxy app name**. - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an on-premises server that is registered in Runtime Manager. See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more information. 1. Select a target from the list or click **Add server**. 2. Enter a **Proxy app name**. - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API proxy to a Mule runtime instance running on an on-premises server that is not registered in Runtime Manager. For more information, see [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model). Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). . [Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises). - **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime engine that is managed on Runtime Fabric. See [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric) for more information. 1. Select a target from the list. 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. 1. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select the **Asset type** from the following options: - **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset. Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML. - **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset. For WebSocket APIs, select HTTP and then choose the WebSocket subtype when selecting the API from Exchange. WebSocket instances can use HTTP or AsyncAPI assets from Exchange. - **SOAP API:** Select this option if you have a WSDL API definition file or an external link to the file. Upload a WSDL file for your SOAP API or add the link to the file. - **GraphQL API:** Select this option if you have a GraphQL schema definition file you want to include for your asset. Upload the GraphQL schema definition for your GraphQL API. 3. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 4. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). 1. Click **Next**. 2. Configure the downstream configuration settings relevant to your proxy type: Connect to existing application (basic endpoint)
Field NameDescriptionRequiredNotes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Manual Approval

Enables manual approval for API Requests.

No

After submitting the instance, you must go to Contracts to approve or revoke the request.

Deploy a proxy application
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

3. Click **Next**. 4. Configure the upstream configuration settings relevant to your proxy type: Connect to existing application (basic endpoint)
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

No

For example, you can use the URL of your API asset in Exchange.

Deploy a proxy application
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

5. Click **Next**. 6. Review your selections and edit them if necessary. 7. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. \== Create New API Asset > [!NOTE] This feature is only available on GovCloud environments. If you want to create an API > asset in other environments, refer to > [exchange::to-create-an-asset.adoc#create-an-api-asset](https://docs.mulesoft.com/exchange/to-create-an-asset#create-an-api-asset) An API asset specifies an interface completely, including its functions, descriptions, how to handle return codes, and dependencies. Creating an asset sets the asset type, which cannot be changed. All versions of an asset always have the same type. To create an API asset: 1. In API Manager, click **Add API**. 2. From the dropdown list, select **Create new API asset** 3. Enter a name for the asset. 4. Select the asset type from the drop-down list: - REST API - RAML: Provide a RAML API specification file. RAML specifications must be a RAML file (.raml). - REST API - OAS: Provide an OAS API specification file. OAS specifications can be either a YAML (.yaml) or JSON (.json) file. Exchange supports OAS 2.0, OAS 3.0, and OAS 3.1 specifications. - SOAP API - WSDL: Provide a WSDL API specification file. SOAP specifications file can be either a WSDL (.wsdl) or XML (.xml) file. - AsyncAPI: Provide an AsyncAPI specification file in a YAML (.yaml) or JSON (.json) file. - AsyncAPI with Avro schemas: Provide an Avro fragment in an AVSC (.avsc) file. - API Spec Fragment - RAML: Provide an API Fragment RAML specification file. Fragment specifications must be a RAML file (.raml). - API Spec Fragment - JSON: Provide an API Fragment JSON specification (.json) file. - API Spec Fragment - OpenAPI Specification (OAS): Provide an API Fragment OpenAPI specification file either JSON or YAML. - HTTP API: This asset does not require a file. This asset type provides an API endpoint that is defined by API Manager. 5. For assets that require a file: 1. Click **Choose File** to locate the API specification file. 2. Select the main file of the API. If the file is a ZIP, the selected main file must be in the root directory of the ZIP file. If the file is not a ZIP or if the file is a ZIP file with only one main file, then the main file is selected automatically. 6. If you want to edit the **GroupId**, **AssetId**, **Version**, and **API version** (GAV), click **Advanced**. Exchange generates the group ID, asset ID, and version (GAV) for you, and you can change these values as needed. You can change an API’s asset version and version separately. Use the advanced settings to change the asset version. 7. Choose an option for **Lifecycle state**. The default is Stable. 8. Click **Publish**. ## Promote an API Instance from Another Environment 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Promote API from environment**. 3. Select the **Source Environment**. 4. Select the **API** by entering the name of the API into the search field. 5. Select the **API Version**. 6. Select the **API instance label**. 7. Optionally, uncheck any of the **Include in Promotion** options you want to exclude. 8. Click **Promote**. 9. Review and update the Runtime & Endpoint Configuration details as needed and click **Save**. ## Import API from Zip File 1. Navigate to **Anypoint Platform** > **API Manager**. 2. From **API Administration**, click **Add API** and select **Import API from zip file**. 3. Click **Choose file** and select your API instance configuration zip file. 4. Click **Next**. 5. Review and update the API Configuration details as needed and click **Save**. ## Notes - Although OpenAPI Specification (OAS) 3.0 and 3.1 are supported, the callback feature is not. To work around this issue, either handle the callback outside of the Mule runtime engine domain or use an OAS 3.0 or 3.1 specification that does not use callbacks. --- product: API Manager version: 2.x is-latest-version: true --- # Adding an MCP Bridge Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Omni Gateway MCP Bridge enables you to create MCP servers from your APIs. With the MCP Bridge, you can expose your APIs as MCP tools so agents can discover and call them. Define your MCP bridge by selecting APIs and mapping them to MCP tools. When an agent requests the list of available tools (`tools/list`), the gateway responds with an MCP descriptor that defines each tool’s name, description, and input schema. When an agent calls a tool (`tools/call`), the MCP Bridge maps the tool name and arguments to an HTTP request based on your configuration. This diagram shows the relationship of the upstream and downstream configurations to your upstream service and agent client: ![The MCP Bridge instance is deployed on a gateway between the upstream apis and downstream configuration](/mulesoft/current/en-us/api-manager/latest/_images/mcp-bridge-instance.png) > [!NOTE] MCP Bridge doesn’t support API instances with multiple upstream services. > [!NOTE] After deploying an MCP Bridge, you can update its configuration, including the APIs and > their versions. See [Update an MCP Bridge](#update-bridge). ## Add a New Agent or Tool Instance To add and a new MCP Bridge for Omni Gateway: 1. Ensure that all APIs you want to add to your MCP Serve exist in Exchange. 2. To begin creating your MCP Server instance, you can start from these locations: - From **API Instances**: 1. Click on an existing API instance you want to add to an MCP Server. 2. Click **Actions** > **Add to new MCP Server instance**. - From **Agent and Tool Instances**: 1. Click **Add** > **MCP Bridge**. 3. From **Select a gateway**, choose an Omni Gateway for deploying the MCP server instance. 4. Click **Next**. 5. Select the APIs you want to add to your MCP Server. 6. Define the MCP server’s asset name. 7. Click **Next**. 8. Configure the downstream configuration settings: Managed Omni Gateway
Field NameDescriptionRequiredNotes

Base path

Specifies the URL prefix for all instance paths, relative to the host root. It must start with a leading slash /.

Yes

Client provider

Specifies a client provider for the instance.

No

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Instance label

Specifies a label for the instance.

No

If you have multiple managed instances of the same asset, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Self-Managed Omni Gateway (Connected Mode)
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

TLS Context used for the inbound HTTPS traffic.

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your server.

Port

Specifies the number to use if the displayed port is incorrect.

No

Instances can share the same port across the same target if the Base path is different for both instances.

Base path

Specifies the URL prefix for all server paths, relative to the host root. It must start with a leading slash /.

Yes

Instance label

Specifies a label for the instance.

No

If you have multiple managed instances of the same asset, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

9. Click **Next**. 10. Configure the upstream services for your API instances:

Field Name

Description

Required

Notes

Route Label

Label to better identify multiple API instances.

Yes

By default, the label is the API name.

Upstream URL

URL to access for the upstream service. This must end with a /.

Yes

For example, use the URL of your asset in Exchange.

Outbound TLS

TLS Context used for the outbound traffic to the upstream service

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your server.

To switch among API instances, select the name of the API. 11. Click **Next**. 12. Define your API Tools: 1. Select an API to map to a tool. 2. Select an HTTP request **Method** and **Resource**. 3. Define an **AI tool name**. 4. Write a tool **Description**. 5. Review the suggested **Input schema** and update it if needed. 13. Optionally, click **HTTP mapping** edit the autopopulated HTTP mapping: 1. Map incoming tool params to: - **Query Parameters** - **URI Parameters** - HTTP **Headers** - Payload **Body** 2. Define DataWeave expressions to extract the tool parameters from the incoming request. 14. Click **Next**. 15. Review your selections and edit them if necessary. 16. If you are ready to deploy, click **Save & Deploy**. Otherwise, select **Save** to deploy the instance later. ## Update an MCP Bridge You can update an existing MCP Bridge instance to change its APIs or configuration settings. To update an MCP Bridge instance: 1. In **Agent and Tool Instances**, click the MCP Bridge instance you want to update. 2. Click **Actions** > **Edit**. 3. In the **APIs** section, click the edit icon to update the APIs associated with this MCP Bridge. 4. To change the API version, select a different version from the **Select version** dropdown. 5. Click through the remaining steps to review and update any other settings as needed. 6. Click **Save & Deploy** to apply the changes. ## See Also - [API Manager Overview](https://docs.mulesoft.com/api-manager/latest/latest-overview-concept) - [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) - [Downloading Omni Gateway](https://docs.mulesoft.com/gateway/latest/install) - [Registering and Running Omni Gateway in Connected Mode](https://docs.mulesoft.com/gateway/latest/conn-reg-run) --- product: API Manager version: 2.x is-latest-version: true --- # Adding an MCP Server from Public Exchange > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This workflow describes how to create an MCP server in API Manager by selecting an asset published in the public Exchange (Provided by MuleSoft). To base a new instance on an MCP server published to Exchange and maintained outside your organization, use this workflow. ## Add an MCP Server or Agent Instance from Public Exchange 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Select an instance type. 3. Click **Add** to start the guided experience. 4. Click **Next** until you reach the **Select asset from Exchange** step. 5. In **Organization**, select **Provided by MuleSoft**. Selecting **Provided by MuleSoft** lets you browse and search assets that are publicly available in Exchange. 6. To find an asset, search by name or filter using the **Provided by Mulesoft** tag. Use tags to narrow down the list of available assets. 7. Select an asset from the list. The asset list shows the latest available version and the date it was published to Exchange. You can select a different version if needed. 8. To review the asset details before continuing, click **View in Exchange**. 9. Click **Next**. > [!NOTE] When you select an asset from **Provided by MuleSoft**, API Manager automatically > populates the instance metadata from Exchange, including the asset name and version. 1. Continue through the remaining steps of the guided experience to configure the instance. The remaining configuration steps are the same as when creating an instance from a private Exchange asset. 2. Review the configuration and click **Save**. ## What Happens Next After the instance is created, you can manage it in API Manager like any other instance. This includes applying policies, viewing instance details, and monitoring its status. Public Exchange assets are treated as read-only sources. The instance maintains a reference to the original Exchange asset rather than copying it into your organization’s private Exchange. ## See Also - [API Manager Overview](https://docs.mulesoft.com/api-manager/latest/latest-overview-concept) - [Anypoint Exchange Overview](https://docs.mulesoft.com/exchange/) - [Adding an Omni Gateway Agent or Tool Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-agent-tool) --- product: API Manager version: 2.x is-latest-version: true --- # Adding an Omni Gateway Agent or Tool Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Use Omni Gateway for any agent, broker, LLM, or MCP server that needs a flexible and performant gateway that works with distributed and microservices environments and fits into your CI/CD environments. This diagram shows the upstream and downstream configurations of the instance. In this configuration, the downstream service is the service making requests that are completed by the upstream service. These terms represent the direction of dependency, not the direction of information. ![The instance is deployed on a gateway between the upstream and downstream configuration](/mulesoft/current/en-us/api-manager/latest/_images/server-upstream-downstream-config.png) ## Add a New Agent or Tool Instance To add and manage server instances for Omni Gateway, use the **Agent and Tool Instances** section in API Manager. These server instances can represent Agents, MCP servers, or LLM servers that extend Omni Gateway functionality. 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **Agent and Tool Instances**. 3. Click **Add** and select the protocol: **Agent**, **MCP Server**, or **LLM**. 4. Select an Omni Gateway to deploy the server instance to from **Select a gateway**. > [!NOTE] If you don’t see an Omni Gateway listed, or you see an Omni Gateway but its status is > **Not Running**, See [Install Omni Gateway](https://docs.mulesoft.com/gateway/latest/install) and > [Register and Run in Connected Mode](https://docs.mulesoft.com/gateway/latest/conn-reg-run) for more information. 5. Click **Next**. 6. Select an instance: - **Select asset from Exchange**: To manage an agent or tool asset shared through Exchange. - Select the asset from **Select asset**. You can also search for an asset. - **Create a new asset**: To create a new asset. - In **Asset name**, enter a name for the new asset. > [!NOTE] Your asset is published to Exchange after it’s protected. 7. Click **Next**. 8. Configure the downstream configuration settings: Managed Omni Gateway
Field NameDescriptionRequiredNotes

Base path

Specifies the URL prefix for all instance paths, relative to the host root. It must start with a leading slash /.

Yes

Client provider

Specifies a client provider for the instance.

No

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Instance label

Specifies a label for the instance.

No

If you have multiple managed instances of the same asset, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Self-Managed Omni Gateway (Connected Mode)
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

TLS Context used for the inbound HTTPS traffic.

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your server.

Port

Specifies the number to use if the displayed port is incorrect.

No

Instances can share the same port across the same target if the Base path is different for both instances.

Base path

Specifies the URL prefix for all server paths, relative to the host root. It must start with a leading slash /.

Yes

Instance label

Specifies a label for the instance.

No

If you have multiple managed instances of the same asset, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

9. Click **Next**. 10. Configure one of the server upstream configurations:
Field NameDescriptionRequiredNotes

Upstream URL

URL to access for the upstream service. This must end with a /.

Yes

For example, you can use the URL of your asset in Exchange.

Outbound TLS

TLS Context used for the outbound traffic to the upstream service

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your server.

11. Click **Next**. 12. Review your selections and edit them if necessary. 13. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. \== Edit Agent Network Project Instances Some instances in **Agent and Tool Instances** can be created by supplying a YAML file in an agent network project. For instances created with the YAML file, the YAML file is treated as the source of truth. If you edit the instance in API Manager (for example, to add policies), the changes are reverted to the YAML file when the instance is redeployed from the agent network project. To ensure changes to instances created from a YAML source are present after redeployment, edit the YAML source. For more information, see [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification). ## See Also - [API Manager Overview](https://docs.mulesoft.com/api-manager/latest/latest-overview-concept) - [Defining Agent Networks](https://docs.mulesoft.com/agent-network/latest/af-define-your-agent-network-specification) - [Downloading Omni Gateway](https://docs.mulesoft.com/gateway/latest/install) - [Registering and Running Omni Gateway in Connected Mode](https://docs.mulesoft.com/gateway/latest/conn-reg-run) --- product: API Manager version: 2.x is-latest-version: true --- # Adding an Omni Gateway API Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you have created an API using Design Center or any other application, you can then manage that API in API Manager by adding an API instance. API instances remain under management until you delete them. Use Omni Gateway for any APIs that need a flexible and performant API gateway that works with distributed and microservices environments and fits into your CI/CD environments. There are three options for adding an API instance: - [**Add a new API:**](#add-api) Select this option to add a completely new instance of an API. - [**Promote API from environment:**](#promote-api) Select this option if you have an API instance in a different environment, for instance the sandbox environment, and you want to promote it to the current or production environment. - [**Import API from zip file:**](#import-api) Select this option if you have exported an API instance from a different Anypoint Platform instance. When you are promoting or importing an API instance, you do not have options to alter the configuration. However, when you add a new API instance, you need to the downstream and the upstream configuration settings. The following diagram shows the relationship of the upstream and downstream configurations settings to your upstream service and the downstream consumer application. In this configuration, the downstream service is the service making API requests that are completed by the upstream service. These terms represent the direction of dependency, not the direction of information. A downstream service could make a `POST` request where it provides information to the upstream service. However, the downstream service is still dependent on the upstream service to complete the request. ![The API instance is deployed on a gateway between the upstream and downstream configuration](/mulesoft/current/en-us/api-manager/latest/_images/api-upstream-downstream-config.png) ## Add a New API 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add** and select **Add new API**. 3. Select **Omni Gateway**. 4. Select a connected Omni Gateway you have installed and registered from the list under **Select a gateway**. > [!NOTE] If you don’t see an Omni Gateway listed, or you see an Omni Gateway but its status is > **Not Running**, See [Install Omni Gateway](https://docs.mulesoft.com/gateway/latest/install) and > [Register and Run in Connected Mode](https://docs.mulesoft.com/gateway/latest/conn-reg-run) for more information. 5. Click **Next**. 6. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select the **Asset type** from the following options: - **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset. Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML. - **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset. For WebSocket APIs, select HTTP and then choose the WebSocket subtype when selecting the API from Exchange. WebSocket instances can use HTTP or AsyncAPI assets from Exchange. - **SOAP API:** Select this option if you have a WSDL API definition file or an external link to the file. Upload a WSDL file for your SOAP API or add the link to the file. - **GraphQL API:** Select this option if you have a GraphQL schema definition file you want to include for your asset. Upload the GraphQL schema definition for your GraphQL API. 3. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 4. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). 7. Click **Next**. 8. Configure the downstream configuration settings: Managed Omni Gateway
Field NameDescriptionRequiredNotes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Client provider

Specifies a client provider for the API.

No

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Self-Managed Omni Gateway (Connected Mode)
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

TLS Context used for the inbound traffic of HTTPS APIs

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your API. Only available on Omni 1.4.0+.

Port

Specifies the number to use if the displayed port is incorrect.

No

API instances can share the same port across the same target if the Base path is different for both instances. Only available on Omni 1.2.0+.

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Manual Approval

Enables manual approval for API Requests.

No

After submitting the instance, you must go to Contracts to approve or revoke the request.

9. Click **Next**. 10. Configure one of the following upstream configurations: - **Single Upstream Service** For Omni Gateway versions 1.4.x or earlier or Omni Gateway version 1.5.x with a single upstream service, configure the following upstream configuration settings:
Field NameDescriptionRequiredNotes

Upstream URL

URL to access for the proxy or API. This must end with a /.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

TLS Context used for the outbound traffic to the upstream service

No

Configure a TLS Context for Omni Gateway before adding a TLS Context to your API. Only available on Omni 1.4.0+.

- **Multiple Upstream Services** Omni Gateway version 1.5.x or later supports API instances that expose multiple upstream services through a single consumer endpoint. To configure multiple upstream services, see [Multiple Upstream Services for Omni Gateway Running in Connected Mode](#traffic-management). 11. Click **Next**. 12. Review your selections and edit them if necessary. 13. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. ## Multiple Upstream Services for Omni Gateway Running in Connected Mode Omni Gateway version 1.5.x or later supports API instances that expose multiple upstream services through a single consumer endpoint. Omni Gateway manages request traffic by using different routes that can each direct traffic to multiple upstream services. Omni Gateway directs traffic to the routes by using the route order and the individual route’s rules. Additionally, you can add a weighted percentage to each upstream service within a route to manage the percentage of requests sent to the upstream service. In the following diagram, different routes manage requests to flight information databases and to a customer service application. Route one has two upstream services defined, which direct 70% of requests to a stable database and 30% of requests to a beta database. ![Omni Gateway manages the traffic to multiple upstreams](/mulesoft/current/en-us/api-manager/latest/_images/multiple-upstreams.png) ### Limits For the upstream service and route limits that apply to each API, see [Omni Gateway Limits and Performance Metrics](https://docs.mulesoft.com/gateway/latest/review-prerequisites#limits). ### Routes Each API instance supports up to 100 routes and each route can support up to 10 upstream services. Configure what requests a route can receive by defining route rules and a route order. At least one route per API instance is required. Before adding additional routes, enter an optional **Route label** for clarity. You can add additional routes by clicking **Add Route**, and you can delete routes by clicking the **Trash Can** icon (![2%](/mulesoft/current/en-us/api-manager/latest/_images/trash-can-icon.png)). If only one route is defined, you cannot delete that route. #### Route Rules You can direct requests to different routes by using route rules. To view and edit route rules, click **Route Rules**. All rules are optional. If a rule does not have a value, that rule is ignored. For example, not specifying a host means that the route can service any host if the request meets the other route rules. Not defining any rule means that the route can service every request. Different routes can support the same upstream services. If you cannot capture all requests for a particular set of upstream services in a single route rule set, you can define multiple routes with different rules for full coverage. Only requests that meet all of the rules defined in the ruleset are directed to that route. If a request does not meet the rules for any route, Omni Gateway returns a `404` error code. Omni Gateway supports the following route rules: Method Defines the types of request methods that the route can service. You can select multiple methods for each route. Only requests that are one of the defined methods are directed to this route. To select the supported methods: 1. Expand the **Method** drop down list. 2. Select all supported methods. 3. Collapse the drop down list. Path Defines the request path that the route can service. You can define only one “URI Template Regex" path for a route. Only requests with the defined path are sent to this route. To define the **Path** rule: 1. Enter your path template in the **Path** configuration field. To route requests to the upstream URL without appending the request path, add an empty capture group, `()`, to the path. For example, with the path `/test()` and the upstream URL `[https://www.upstream.com/help](https://www.upstream.com/help)`, requests to `/test` go to `[https://www.upstream.com/help](https://www.upstream.com/help)`. This is useful for SOAP services, where clients call a fixed WSDL URL and the `SOAPAction` header determines the operation. For more information, see [Route Requests to an Unrelated Upstream Path](https://docs.mulesoft.com/gateway/latest/policies-included-traffic-management-route#empty-capture-group). Host Defines the request host that the route can service. You can define only one host URL for each route. Only requests made from the defined host are sent to this route. To define the **Host** rule: 1. Enter your host in the **Host** configuration field. Header Defines what headers and regular expression value must be present for this route to service the request. For this rule, you define the header name and a regular expression value. Only requests that meet all of the specified header requirements are sent to this route. Additional headers present in the request that are not specifically defined in the rules are ignored. You can define up to 10 headers. To define the **Headers** rule: 1. Click **Add header**, if this is not your first header. 2. Enter the header name in the first box. 3. Enter the header’s regular expresion value in the second box. > [!NOTE] To delete a header, click the **Trash Can** icon (![2%](/mulesoft/current/en-us/api-manager/latest/_images/trash-can-icon.png)). #### Route Order In addition to using route rules, Omni Gateway directs requests to different routes by using the top to bottom order of how the routes appear on the page. Omni Gateway directs requests to the first route if the request meets the route rules. To define the route order, use the up and down arrows to arrange the routes. Route ordering is very important when a request can meet the route rules of multiple routes. You should order the routes with more complex route rules first. If you do not define a route order, routes are ordered in the order they were created. For example, in a configuration in which route one has the `GET` method defined as a rule and route two has no route rules defined, all `GET` requests are sent to route one and all other requests are sent to route two. If the route order was reversed and route one had no route rules, Omni Gateway would direct all requests to route one before any `GET` requests could reach route two. ### Upstream Services You can use multiple upstream services in a single route to direct requests to similar services. For example, to test the performance of a new beta upstream service without sending all traffic to the new service, you can direct half of the traffic to a stable upstream service and half to the new upstream service. Each API instance route can support up to 100 upstream services, but at least one upstream service is required for each route. What upstream service within the route each request is sent to is random and independent of any previous request. The upstream **Weight** defines the percentage chance of a request being sent to a particular upstream service. Because any upstream service within a route can receive any request, all upstream services within the same route must adhere to the same API contract. You can add an upstream service by clicking **Add Upstream**, and you can delete an upstream service by clicking the **Trash Can** icon (![2%](/mulesoft/current/en-us/api-manager/latest/_images/trash-can-icon.png)). If only one upstream service is defined, you cannot delete it. Configure the following fields for each upstream service:
Field NameDescriptionRequiredNotes

Upstream URL

URL to access for the proxy or API. This must end with a /.

Yes

For example, you can use the URL of your API asset in Exchange.

Upstream Label

Label for the upstream service

No

If you have multiple upstream service instances, add a label to each one to differentiate it from the others.

TLS

TLS context used for the outbound traffic to the upstream service

No

Configure a TLS Context for Omni Gateway before adding a TLS context to your API. Add a TLS context by clicking Add TLS Context.

Weight

Percentage of requests to send to that upstream service

Yes

This value is configurable only if you have multiple upstream services. The sum of all upstream weights must equal 100%.

## Promote an API Instance from Another Environment 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Promote API from environment**. 3. Select the **Source Environment**. 4. Select the **API** by entering the name of the API into the search field. 5. Select the **API Version**. 6. Select the **API instance label**. 7. Optionally, uncheck any of the **Include in Promotion** options you want to exclude. 8. Click **Promote**. 9. Review and update the Runtime & Endpoint Configuration details as needed and click **Save**. ## Import API from Zip File 1. Navigate to **Anypoint Platform** > **API Manager**. 2. From **API Administration**, click **Add API** and select **Import API from zip file**. 3. Click **Choose file** and select your API instance configuration zip file. 4. Click **Next**. 5. Review and update the API Configuration details as needed and click **Save**. ## Notes - Although OpenAPI Specification (OAS) 3.0 and 3.1 are supported, the callback feature is not. To work around this issue, either handle the callback outside of the Mule runtime engine domain or use an OAS 3.0 or 3.1 specification that doesn’t use callbacks. --- product: API Manager version: 2.x is-latest-version: true --- # Anypoint DataGraph Administration > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You manage Anypoint DataGraph in API Manager. The DataGraph Administration page for a given environment appears only after you have added at least one API schema to that environment’s unified schema. Both Anypoint DataGraph administrators and contributors can: - Use the [Anypoint DataGraph Administration settings](https://docs.mulesoft.com/api-manager/latest/datagraph-settings) to select environments, view and edit the GraphQL endpoint of a unified schema, configure policies, and configure client providers. - Manage [contracts](https://docs.mulesoft.com/api-manager/latest/datagraph-managing-contracts) to ensure that only authorized client applications can consume the unified schema. - Manage [SLA tiers](https://docs.mulesoft.com/api-manager/latest/datagraph-adding-sla-tiers) for each Anypoint DataGraph instance. - Use the [API Manager Client Applications](https://docs.mulesoft.com/api-manager/latest/datagraph-viewing-application-contracts) page to view and manage client application contracts. ## See Also - [Anypoint DataGraph Overview](https://docs.mulesoft.com/datagraph/) --- product: API Manager version: 2.x is-latest-version: true --- # Anypoint DataGraph Administration Settings > For the full documentation index, see: https://docs.mulesoft.com/llms.txt On the DataGraph Administration settings page, you can select environments, view and edit endpoints, configure policies, and configure client providers: ![The illustration shows the Anypoint DataGraph Administration page](/mulesoft/current/en-us/api-manager/latest/_images/datagraph-settings.png)
1Switch Environment control. Click the control to see a list of environments you have added to your organization. Select an environment to switch.
2Consumer endpoint edit options. To edit the current endpoint, click the Edit consumer endpoint icon. To revert to the system-generated endpoint, click the Revert icon.
3DataGraph Policies configuration options. You can choose to restrict requests to your unified schema from registered client applications only, set SLA-based rate limiting for requests, or allow requests from anyone with access to the unified schema’s endpoint.
4DataGraph external client providers control. To see a list of external client providers previously configured by your organization administrators, click the control. Select a provider from the list. To run queries in Anypoint DataGraph, obtain proper credentials from the external client provider.

If your administrators haven’t configured any external client providers, this item is not available.

## See Also - [Permissions for Anypoint DataGraph](https://docs.mulesoft.com/datagraph/permissions) - [Anypoint DataGraph Supported Authentication Methods](https://docs.mulesoft.com/datagraph/security) --- product: API Manager version: 2.x is-latest-version: true --- # API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Using API Groups enables you to bundle your APIs and resources to solve specific user needs. Instead of using individual resources and APIs from a list, the users can request access to and use these in a package that solves a specific problem for them. When you create an API Group, you can customize instances of that group with different SLAs and rate limit conditions based on the problem the instance must solve. You can then publish the API Group to Anypoint Exchange so that users can subscribe to the package. Because each API Group instance can include several API instances, and each instance can be included in multiple API Group instance solutions, package customization options are limitless. ## How API Groups Work As an API Group Administrator, you create an API Group for a specific organization and environment. API Groups are versioned, like the APIs contained within them, to more easily incorporate updates. Each API Group can have multiple instances and each API Group instance can have multiple API instance. These API Group instances can exists in different environments, such as production and sandbox. The following graphic illustrates how you can implement API Groups in different environments: ![API Group Hierarchy](/mulesoft/current/en-us/api-manager/latest/_images/api-groups-architecture.png) In this example, we have two business groups: `ORG A` and `ORG B`. Each of these business groups has two environments: `Sandbox` and `Production`. `ORG A` has two APIs: `Twitter` and `Facebook`, and one instance of each of these APIs in the two environments. `ORG B` has two APIs: `Instagram` and `Snapchat`, and one instance of each of these APIs in the two environments. `ORG A` has one API Group called `Social Media` with one version `V1`. `Social Media V1` has two API Group instances: - API Group instance `QA` in `Sandbox` environment. This instance has 4 API instances: `Facebook v1` (QA) and `Twitter v1` (QA) from `ORG A` and `Instagram v1` (QA) and `Snapchat v1` (QA) from `ORG B`. - API Group instance `PROD` in `Production` environment. This instance has 4 API instances: `Facebook v1` (PROD) and `Twitter v1` (PROD) from `ORG A` and `Instagram v1` (PROD) and `Snapchat v1` (PROD) from `ORG B`. The API Group instance `QA` is published and an asset called `API Group Social Media V1` is created. If the API Group instance `PROD` is published, no asset is created. In this case, `PROD` is linked only to the existing asset because the API Group `Social Media` and the version `v1` are the same. ## API Groups Example To better understand how API Groups facilitate API consumer engagement, consider the needs of a fictitious company named Good Weather, which forecasts atmospheric conditions for a given location and time by using meteorology. Good Weather enables customers to access requested results using the following APIs: - Locations API - Forecast API - Current Conditions API - Indices API - Weather Alarms API - Alerts API - Imagery API - Tropical API - Translations API ### Example Problem Statement The process that Good Weather customers follow to access and use the APIs is not efficient, requiring: - Searching the Good Weather company portal to find appropriate APIs to actualize a business flow To determine the precise API they need, customers have to search a long list of APIs on the portal. This difficulty is compounded when developers modify the existing APIs or introduce additional APIs. - Changing multiple API service plans individually to adopt a service-wide change This complicates the task of upgrading or downgrading of services. - Working to access each element of an API when API access is approved The API packaging does not restrict access down to the individual call and data elements. This introduces security issues and unnecessary overhead. ### Example Solution using API Groups Using API Groups, Good Weather can package different APIs based on consumer requirements and scenarios, with specific SLAs that do not conflict with the requirements for other consumers. Good Weather can quickly adapt and absorb API changes. Using API Groups: - Good Weather can package different sets of APIs to target different consumers' requirements. - API consumers can access a collection of related APIs instead of individual APIs, simplifying asset discovery on the Good Weather portal. - API Groups can enforce governance using SLA plans that can be modified with a single click. The following table illustrates the API Group packages that Good Weather created to meet their business requirements:
TrialBaseEnterprise

Locations API

Locations API

Locations API

Forecast API

Forecast API

Forecast API

Current Conditions API

Current Conditions API

Weather Alarms API

Weather Alarms API

Alerts API

Imagery API

Translations API

## API Group Permissions To perform all tasks pertaining to API groups, the API Group Administrator permission is required. This permission is set at the business group-level and gives the user access to: - Create, update, and delete API Groups within the business group - View all API instances in the business group to be able to add API instances to the API Group - Configure SLA tiers and manage contracts with API Groups ## See Also - [API Group Limits](https://docs.mulesoft.com/api-manager/latest/limits#api-group-limits) --- product: API Manager version: 2.x is-latest-version: true --- # API Manager 2.x > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you created an Anypoint Platform account prior to November 2017, use the API Manager 1.x documentation listed in the version menu in the sidebar. If you created an Anypoint Platform account after November 2017: - Use API Manager 2.x to manage APIs. - Use Design Center to author and update RAML specifications. Applications are automatically deployed to CloudHub when you use Design Center to develop your APIs. - Use API Manager to deploy an API proxy to other servers. - You can manage Mule runtime engine 4.x APIs only with API Manager 2.x. --- product: API Manager version: 2.x is-latest-version: true keywords: api, manager, raml --- # API Manager Overview > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint API Manager (API Manager) is a component of Anypoint Platform that enables you to manage, govern, and secure APIs and server instances. It provides an interface to configure the runtime capabilities of Omni Gateway, Anypoint Mule Gateway, and server instance types such as Agents, MCP servers, and LLM servers. API Manager helps organizations implement API governance policies, monitor API performance, manage server connectivity, and ensure security compliance across their API ecosystem. The tool supports both cloud and on-premises deployments, making it suitable for various enterprise environments. With API Manager you can: - Enforce policies - Collect and track analytics data - Manage proxies, server instances, and client applications - Provide encryption and authentication API Manager is tightly integrated with the following tools: - [Design Center](https://docs.mulesoft.com/design-center/): To specify the structure of the API - [Exchange](https://docs.mulesoft.com/exchange/): To store and publish API and server assets - [Studio](https://docs.mulesoft.com/studio/): To implement the API - [Runtime Manager](https://docs.mulesoft.com/runtime-manager/): To deploy, manage, and monitor API instances - [API Governance](https://docs.mulesoft.com/api-governance/): To govern API instances Before using API Manager, familiarize yourself with the user interface and the tasks you can perform therein. The following video provides a quick overview of API Manager: ![](https://play.vidyard.com/DVBh7B1suty8yk1igmD2FC.jpg) ## What API Manager Looks Like To access API Manager, log in to Anypoint Platform and select **API Manager**: ![API Manager page navigation shown with callouts.](/mulesoft/current/en-us/api-manager/latest/_images/api-manager-ui-overview.png)
1The environment selector. Anypoint Platform enables you to create and manage separate deployment environments for APIs and applications. API Manager displays all environments except design environments. For details, see Switching Environments.
2Sidebar:

  • API Groups

    An API group is an API asset that enables organizations to publish a group of API instances as a single unit. For details, see API Groups.

  • Agent and Tool Instances

    The Agent and Tool Instances tab represents server instances that extend Omni Gateway with additional capabilities such as Agents, MCP servers, and LLM servers. You can add, configure, and manage these server instances directly from this section. For details, see Adding an Omni Gateway Agent or Tool Instance.

  • Automated Policies

    Policy automation enables security architects and administrators to secure and govern every API running in an environment.

  • Client Applications

    Applications are external services that consume APIs. For details about applications and their related contracts, see View API Instance Contracts.

  • Custom Policies

    Custom policies are policies that anyone can develop and apply to their APIs, with the intention of extending existing functionality or defining new functionality.

  • DataGraph Administration

    Anypoint DataGraph enables you to unify all the data within your application network in a unified schema. For details, see Anypoint DataGraph Overview. DataGraph Administration is only visible after you configure a DataGraph unified schema.

  • Mule API Analytics

    Mule API Analytics provide insight into how your Mule APIs are being used and how they are performing. For details, see Reviewing Mule API Analytics Usage.

3The Add API button. Enables you to add a new API instance, to promote an API from any environment to the current environment, or to import a configuration ZIP file that was exported from API Manager. For details, see Getting Started with Managing an Instance.
4The Environment information button, available only to administrator users. Enables administrators to display a dialog with information about the current environment, such as environment credentials. Use environment credentials to configure Studio to sync with your environment.
5Search. Enables you to search for managed APIs using the API search field. Searches are case-insensitive. Filter search results by selecting Active.
6The tracking registration status of each API: Active, Inactive, or Unregistered.

A status of Unregistered means that Anypoint Platform currently has no tracking data for this API version. This can occur if the endpoint has never communicated with the platform (for example, a newly declared proxy or an endpoint hosted outside an API gateway), or if the endpoint was previously active but its last activity record was purged after an extended period of inactivity (approximately 30 days).
The endpoint must have a tracking registration status of Active for governance policies and SLA tiers to function.

7The name of each API. Clicking the API name navigates you to the API Settings view, where you manage the following:
8The percentage of API requests that resulted in errors (in the past 24 hours).

If "No Data" is displayed, automatic monitoring has not been enabled for the API. For details, see Getting Started with Anypoint Monitoring.

9The total number of API requests (in the past 24 hours).

If "No Data" is displayed, automatic monitoring has not been enabled for the API. For details, see Getting Started with Anypoint Monitoring.

10The number of contracted client applications for each API. For details, see Client Applications, Contracts, and Credentials.
### Tracking Registration Status API Manager shows a tracking registration status for each API instance: - **Active**: API Manager is currently receiving activity signals (for example, recent traffic via a registered gateway). - **Inactive**: The API was previously active, but no activity has been observed for a period of time. The last active timestamp is still retained. - **Unregistered**: API Manager has no current tracking data for this API version. This can occur either because the endpoint has never communicated with the platform **or** because tracking data (for example, `lastActiveDate`) was purged after an extended period of inactivity (for example, ~30 days of no activity). > [!NOTE] Governance policies and SLA tiers require the endpoint to be in **Active** status to > function. ## API Manager Components, Concepts, and Features ### API Instances An API instance describes a configuration of an API that is deployed on one of the following runtimes: Omni Gateway or Mule Gateway. API Manager manages API instances after they are created by using the **Add**, **Promote**, or **Import** options. API instances remain under management until they are deleted. API Manager also manages **server instances** (Agent and Tool Instances) that extend Omni Gateway functionality through Agents, MCP servers, or LLM servers. These are managed separately from API instances. For more detail, see [Managing Instances](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page). ### API Summary The API Summary shows key information about a deployed API instance: ![API Summary page](/mulesoft/current/en-us/api-manager/latest/_images/api-instance-summary.png) ### Key Metrics The API Summary page includes a Key Metrics section. The **Key Metrics** section of the API summary contains the following charts: Total Requests Sum of requests in the selected time period for the given API. Data is aggregated in one minute increments. Total Policy Violations Sum of requests that return policy violations. Data is aggregated in one minute increments. Total Errors Sum of HTTP response codes that occur in the selected time period. The response codes counted in this metric are 400, 401, 402, 403, 404, 405, 408, 409, 410, 411, 412, 413, 415, 416, 417, 420, 422, 429, 500, 502, 503, 504, 504, 510, and 511. Data is aggregated in one minute increments. In the chart, HTTP response codes are abbreviated as 4xx and 5xx. Average Response Time Average response time of requests in the selected time period for the given API. Data is aggregated in one minute increments. ## Setting the Time Period for Key Metrics You can view the data points collected for the last given period of time (such as the last 5 or 30 minutes) or over a given date and time range. Use the drop-down in the calendar icon to select the time period to display. ### API Alerts An _API alert_ (different from a Runtime Manager alert) is an alarm that flags one of the following: - The API request violates a policy. - Requests received by the API exceed a given number within a specified period of time. - The API returns a specified HTTP error code. - The API response time exceeds a specified timeout value. API Manager triggers alerts when states change from desirable to undesirable or vice versa. When an alert is triggered, API Manager sends an email notification to you and to anyone else you specify in the configuration. For details, see [Reviewing Alerts Concepts](https://docs.mulesoft.com/api-manager/latest/using-api-alerts). ### Contracts Contracts define how client applications consume APIs. A client application requests access in Exchange. Either the owner of the API instance approves the request in API Manager or the approval is automatic, depending on configuration. Contracts are enforced with either of the following: - SLA enforcement policies - Client enforcement policies For details about enforcement policies, see [Client Applications, Contracts, and Credentials](https://docs.mulesoft.com/api-manager/latest/api-contracts-landing-page). ### Policies Policies enable you to enforce regulations to help manage security, control traffic, and improve adaptability of your APIs. For example, a policy can control authentication, access, allotted consumption, and service level access (SLA). API Manager supports the following types of policies: - Default policies - Custom policies For details, see [Securing Omni Gateway Instances with Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis). ### SLA Tiers _Service Level Access (SLA) tiers_ are categories of user access that you define for an API. The tier definition combined with an SLA-based policy determines whether access to the API at a certain level requires your approval. The tier definition also can limit the number of requests an application can make to the API. To enforce SLA tiers, you need to apply a rate-limiting or throttling policy that is SLA-based. For details, see [Reviewing SLA Tiers Concepts](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers). ### Settings When adding an API instance, you configure the API instance settings to set parameters such as the runtime and upstream and downstream URIs. To add an API instance, see [Add API Instances](https://docs.mulesoft.com/api-manager/latest/add-api-instances). After you create the API instance, you can edit the configuration settings from Settings. To edit an API instance, see [Editing an API Instance](https://docs.mulesoft.com/api-manager/latest/edit-api-endpoint-task). ### Governance Report API Governance is integrated with API Manager to identify the conformance status of your API instances. API Governance tests API instances against rulesets to determine conformance issues such as missing policies and missing TLS contexts. You can view the governance validation report details to get the information you need to fix conformance issues. The validation report is available both in API Manager on the Governance Report page and in API Governance. To learn more about governing your API instances, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). ### Client Providers (Identity Providers) You use client providers to enforce security and regulations in your business organization. Client providers authorize client applications. For details about using client providers, see [Configure Multiple Client Providers for Client Management](https://docs.mulesoft.com/api-manager/latest/configure-multiple-credential-providers). ### API Assets API assets, published by Exchange, are the components that comprise applications. Components include any of the following: - APIs (OAS, RAML, RAML fragments, HTTP, WSDL, and custom) - API groups - Policies - Examples - Templates - Modules - Connectors For details about sharing assets via a private Exchange or an Exchange public portal, see [Publishing Assets](https://docs.mulesoft.com/exchange/about-sharing-assets). ### API Console When you create or edit APIs in API Manager, use [Building, Implementing, and Testing a REST API](https://docs.mulesoft.com/apikit/latest/apikit-4-implement-rest-api) to expose and test your API specification. You can test RAML and OAS APIs when you manage the API as an endpoint with proxy. The console flow is already included and enabled (by default) in the API specification when you download an out-of-the-box proxy for your Mule application. Starting with Mule 4, you can enable access to API Console and modify the API Console path from API Manager. API Console access from API Manager is disabled by default. For information about how to enable API Console access from API Manager, see [Adding a Mule Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule). ### API Groups An _API group_ is a collection of API instances that act as a single unit, so that applications can access them using one client ID. API groups are created in API Manager and published to Exchange. For details, see [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page). ### Autodiscovery Schemes Through autodiscovery schemes, API Manager can track the API throughout the life cycle as you modify, version, deploy, govern, and publish it. > [!NOTE] Multiple `autodiscovery` elements referencing the same API instance are not supported. > Each Mule application can be linked to only one API instance in API Manager. For API auto-discovery to work, the Exchange asset and the API Manager instance must belong to the same business group. Auto-discovery fails if an API instance in a child business group references an Exchange asset published in a parent business group, even if that asset is visible from the child group. If you need to move an API specification asset to a different business group: 1. Download the asset from its current business group. 2. In the asset’s `exchange.json` file, update the `organizationId` value to match the target business group’s organization ID. 3. Publish the updated asset to the target business group. ### Business Groups A system administrator groups individuals within an organization into business groups. Each group has its own Exchange API assets and its own environments. For details, see [Anypoint Platform Business Groups](https://docs.mulesoft.com/access-management/business-groups). ### Environments Anypoint Platform enables you to create and manage separate deployment environments for APIs and applications. These environments are independent from each other and enable you to test your applications under the same conditions as in your production environment. The support for environments in strategic components of Anypoint Platform eliminates the need to construct version names to reflect an environment. Restricting access to and managing environments is also simplified. Permissions to access APIs are environment-based. For details, see [Anypoint Platform Environments](https://docs.mulesoft.com/access-management/environments). ## See Also - [Tutorial: Build an API from Start to Finish](https://docs.mulesoft.com/general/api-led-overview) - [Adding an Omni Gateway Agent or Tool Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-agent-tool) - [Getting Started with Managing an Instance](https://docs.mulesoft.com/api-manager/latest/getting-started-proxy) - [Anypoint Platform Glossary](https://docs.mulesoft.com/general/glossary) --- product: API Manager version: 2.x is-latest-version: true keywords: api, manager, raml --- # API Manager Release Notes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager automatically updates to the latest version available; you don’t need to perform any tasks to move to the new version. The following release notes are provided for API Manager: - [API Manager 2.x Release Notes](https://docs.mulesoft.com/release-notes/api-manager/api-manager-release-notes) - [API Manager Policies Release Notes](https://docs.mulesoft.com/release-notes/policies/policies-release-notes) - [API Manager Proxy Release Notes](https://docs.mulesoft.com/release-notes/proxies/proxies-release-notes) - [API Gateway Extensions Release Notes](https://docs.mulesoft.com/release-notes/api-gateway-extensions/api-gateway-extensions-release-notes) To take advantage of all new features, improvements, and bug fixes, ensure that you are using the latest version of your runtime. The following release notes are provided for your runtime: - [Omni Gateway Release Notes](https://docs.mulesoft.com/release-notes/gateway/gateway-rn-landing-page) - [Mule Runtime Release Notes](https://docs.mulesoft.com/release-notes/mule-runtime/mule-esb) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: API Manager version: 2.x is-latest-version: true --- # Applying Rate Limiting Policy v1.2.0 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Rate Limiting 1.2.0 includes the capabilities in Rate Limiting 1.0.0 and 1.1.0 plus the capability to apply a quota by a key-sensitive identifier. This policy is available since Mule 4.1.0 The identifier is a DataWeave expression that maps to a String, creating a selector key. In Rate Limiting 1.0.0 and 1.1.0, when you apply the policy to an API, only one rate limiting algorithm is created per policy with the configured limits and an identification. In 1.2.0, the selector key is part of the identification. Therefore, one algorithm is created for each selector key, and they have their own quota. You specify the identifier when you apply the policy. ![The Apply Rate limiting policy page.](/mulesoft/current/en-us/api-manager/latest/_images/rate-limit-identifier.png) This example makes Rate limiting effective for every method. The quota is independent for each method (3 requests per 10 seconds). Such a policy configuration could result in the events over a hypothetical period of time shown below: ![A graphic that shows symbols for accepted and rejected post and get requests on a timeline with brackets showing window sizes for two 10-second intervals.](/mulesoft/current/en-us/api-manager/latest/_images/three-req-per-10.png) The example shows the following things: - Every HTTP Method is allowed 3 requests every 10 seconds (in this example only GET and POST requests have been made to the API). - The Rate Limiting policy works in a fixed window fashion (see the window size bracket). - Window start times are independent: The engine uses a lazy creation strategy that spools a Rate limiting algorithm whenever the first request for a method is received. ## To Apply Rate Limiting Using an Identifier on Non-Obligatory Parameters The identifier is a non-obligatory parameter. By default the identifier is blank, preserving compatibility with all previous versions of the Rate limiting policy as follows: - When not set (blank), the quota limiting applies to every request matched by the policy pointcut, using one bucket. - When set for an obligatory HTTP header, each case-sensitive value of the header has its own quota. Quotas are created lazily. - When set for a non obligatory HTTP header, custom header, payload, query parameter or expression, each value has its own quota. If the identifier is not sent in the request, it defaults to an empty identifier, having its own quota. This behavior allows the Rate limiting policy to be applied to an API consumed by uncontrolled clients, and at the same time accommodates special buckets for the clients sending the identifier (which may be internal controlled services). The following image illustrates the latter case, which corresponds to a 3-requests-per-10-seconds quota with the DataWeave expression: `#[attributes.queryParam[‘customIdentifier’]]` as the policy identifier: ![The Apply Rate limiting policy page.](/mulesoft/current/en-us/api-manager/latest/_images/rate-limit-identifier.png) In the case, the following actions occur: - All requests without the identifier are resolved to the empty identifier, and therefore use a single rate limiting algorithm. - Each different identifier uses a different bucket, with its own independent quota. ## To Apply Rate Limiting Using DataWeave Expressions The rate limiting engine is HTTP agnostic, depending solely on the resolution of the DataWeave expression. You can alter the identifier expression to cover complex rate limiting scenarios. For example, you can configure a rate limiting policy with an identifier that uses one bucket for all Class A & C LAN requests, and another one for everything else. ![The Apply Rate limiting policy page with identifier attributes highlighted.](/mulesoft/current/en-us/api-manager/latest/_images/dw-apply-limiting.png) This configuration creates a false or a true bucket that corresponds to the locality of the IP that made the request. False and true correspond to the domain of boolean values, not HTTP; nevertheless, the policy works correctly because the engine treats the resolved expression as a String. Possible identifiers must extract the result from the request using DataWeave, but otherwise, are unlimited except by your imagination. **Note:** The HTTP RFC declares header names as case-insensitive. The MuleSoft HTTP Connector changes header names to lowercase characters. DataWeave is key-sensitive. Therefore, when creating the identifier expression, remember to reference headers in lowercase. ### Unbounded Identifier Sets As one algorithm must exist for every identifier, carefully create the DataWeave expression not to return an unbounded co-domain (or a very large one), as it will require hosting the same amount of algorithms in memory (if there is at least a request for every possible identifier). For example, suppose the DataWeave expression uses the ip as the identifier in a runtime that is public to the Internet. If every public IPv4 IP in the internet makes a request to this runtime, there will be 3,706,452,992 algorithms running in a single runtime. On an average of 250 bytes per algorithm, this would be approximately 1 terabyte in rate limit algorithms. MuleSoft recommends using a DataWeave expression that resolves to a finite number of identifiers, and to keep the resulting set as small as possible. --- product: API Manager version: 2.x is-latest-version: true keywords: grant access, api, contracts --- # Approve or Reject Access Requests > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After users [request access](https://docs.mulesoft.com/exchange/to-request-access) to your API instance from Anypoint Exchange, you can manually approve or reject requests from API Manager. ## Task Prerequisite To manually approve or reject requests, you must have: - Configured the SLA tier for the application - The Organization Administrator, API Manager Environment Administrator, or the Manage Contracts permission ## Manually Approve Requests To approve or reject requests to access your API: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance to which you are requesting access. 3. Click **Contracts**. The request appears. 4. Click either **Approve** or **Reject** to approve or reject the access request, respectively. ## See Also - [Request Access to API Instances from Exchange](https://docs.mulesoft.com/exchange/to-request-access) - [Remove API Instance Contracts](https://docs.mulesoft.com/api-manager/latest/remove-client-app-latest-task) - [Obtain Client ID and Client Secret Credentials of a Client Application](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task) --- product: API Manager version: 2.x is-latest-version: true keywords: alert --- # Archetype Error When Creating Policies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you attempt to run Archetype from a directory with existing files when you create a policy, you might encounter a “Directory already exists” error. The error might differ based on the Maven version installed in your environment. The following code snippet shows an error generated for maven-archetype-plugin version 3.1.1: ```text mvn -Parchetype-repository archetype:generate \ [INFO] Parameter: basedir, Value: C:\Users\32481\AnypointStudio\studio-workspace\mycustompolicy [INFO] Parameter: package, Value: mule-policy [INFO] Parameter: groupId, Value: 6344d2e6-eff9-4020-b792-719c463d5b92 [INFO] Parameter: artifactId, Value: ClientIdCustomPolicy [INFO] Parameter: packageName, Value: mule-policy [INFO] Parameter: version, Value: 1 [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Skipping mycustompolicy [INFO] This project has been banned from the build due to previous failures. [INFO] ------------------------------------------------------------------------ [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 05:14 min [INFO] Finished at: 2019-07-03T14:07:26+08:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.1.1:generate (default-cli) on project mycustompolicy: Directory ClientIdCustomPolicy already exists - please run from a clean directory -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException. ``` ## Cause This issue occurs because the directory in which Archetype is located already exists. The directory might have been created during a previous attempt to run Archetype. ## Solution To resolve this issue, delete the existing Archetype directory and run the command again. ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: API Manager version: 2.x is-latest-version: true --- # Build HTTPS API Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager 2.x enables you to use the secrets stored in your secret group to build an HTTPS-based API for your CloudHub or hybrid deployments. By configuring a TLS context for your inbound and outbound traffic, you can ensure your traffic’s security. The secrets manager integration is only supported by API Proxies running Mule 4 on CloudHub, Hybrid, or standalone deployments. Supported keystores for the TLS context are JCEKS, PKCS12, and JKS. To build an HTTPS Proxy in a Runtime Fabric deployment target, see [Build an HTTPS Service](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service). ## Before You Begin To configure your HTTPS API Proxy using secrets stored in your secret group, ensure you have: - Requested the following permissions from your Anypoint Platform admin: - Secrets Manager permissions To configure an existing TLS context for the API Proxy, you need the **Read secrets metadata** permission. Review the [Secrets Manager Permissions](https://docs.mulesoft.com/anypoint-security/asm-permission-concept) reference for more information. - API Manager permissions To apply a TLS context to an API proxy in API Manager, you need the **Manage API Configuration** role. See the [API Manager](https://docs.mulesoft.com/access-management/permissions-by-product#api-manager) section of the Permissions by Product page for more information. - [Created a Secret Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task) Enable the **Secret Group Downloadable** checkbox. - [Added a TLS Context](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task#add-a-tls-context) Set TLS context’s target to **Mule**. ## Configure your HTTPS API Proxy Configure your HTTPS API Proxy by completing the following steps: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Add new API**. 3. Select **Mule Gateway** as your runtime. 4. Select **Deploy a proxy application** for **Proxy type**. 5. If you selected to deploy a proxy application, select the **Target type** from the following options: - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores by default. 1. Select a space. To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. 1. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 2. Enter a **Proxy app name**. - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an on-premises server that is registered in Runtime Manager. See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more information. 1. Select a target from the list or click **Add server**. 2. Enter a **Proxy app name**. - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API proxy to a Mule runtime instance running on an on-premises server that is not registered in Runtime Manager. For more information, see [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model). Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). . [Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises). - **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime engine that is managed on Runtime Fabric. See [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric) for more information. 1. Select a target from the list. 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. 1. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select the **Asset type** from the following options: - **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset. Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML. - **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset. For WebSocket APIs, select HTTP and then choose the WebSocket subtype when selecting the API from Exchange. WebSocket instances can use HTTP or AsyncAPI assets from Exchange. - **SOAP API:** Select this option if you have a WSDL API definition file or an external link to the file. Upload a WSDL file for your SOAP API or add the link to the file. - **GraphQL API:** Select this option if you have a GraphQL schema definition file you want to include for your asset. Upload the GraphQL schema definition for your GraphQL API. 3. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 4. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). 1. Click **Next**. 2. Configure the downstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

> [!NOTE] To configure an HTTPS Proxy, you must select **HTTPS** and configure an > **Inbound TLS** context. 3. Click **Next**. 4. Configure the upstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

5. Click **Next**. 6. Review your selections and edit them if necessary. 7. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. ## API Proxy Deployment You can deploy your API proxy to CloudHub, hybrid, or standalone servers. ### Deploy to CloudHub After you configured your API Proxy and selected **CloudHub** as the **Proxy deployment target**, your API Proxy will be automatically deployed, with the secrets already configured. Your secrets are configured as secure property placeholders under the `SecureProperties` in your `mule-artifact.json`. The amount of properties supplied depends on your selected configuration: ```sample inbound.keystore.keyPassword_281324 inbound.keystore.password_281324 inbound.truststore.password_281324 outbound.keystore.keyPassword_281324 outbound.keystore.password_281324 outbound.truststore.password_281324 ``` The `281324` suffix in this case is API instance ID of your API Proxy. If you inspect your API Proxy’s XML, you can see these properties being used in your trustore/keystore configurations: ```xml ``` ### Deploy to Hybrid After you configure your API Proxy and select **Hybrid** as the **Proxy deployment target**, your API Proxy is automatically deployed, with the secrets already configured. Your secrets are configured as secure property placeholders under the `SecureProperties` in your `mule-artifact.json`. \+ The amount of properties supplied depends on your selected configuration: ```sample inbound.keystore.keyPassword_281324 inbound.keystore.password_281324 inbound.truststore.password_281324 outbound.keystore.keyPassword_281324 outbound.keystore.password_281324 outbound.truststore.password_281324 ``` The `281324` suffix in this case is API instance ID of your API Proxy. If you inspect your API Proxy’s XML, you can see these properties being used in your trustore/keystore configurations: ```xml ``` ### Deploy to Standalone Servers To deploy your API Proxy to a standalone server, provide secured properties for each TLS Context. 1. Download the API Proxy. 1. In API Manager, select the version of the API proxy you want to download. 2. Click the **Actions** button in the top-right corner of your screen and select **Download Proxy**. 2. Take note of your API instance ID under **API Instance ID**. 3. When running your standalone Mule instance, you need to provide the keystore and key passphrases as -D arguments, along with your API Proxy’s API instance ID. For example, if your API instance ID is 15464957, you need to pass the arguments: ```sample ./bin/mule \ -M-Dinbound.keystore.keyPassword_15464957=pass123 \ -M-Dinbound.keystore.password_15464957=pass123 \ -M-Dinbound.truststore.password_15464957=pass123 \ -M-Doutbound.keystore.keyPassword_15464957=pass123 \ -M-Doutbound.keystore.password_15464957=pass123 \ -M-Doutbound.truststore.password_15464957=pass123 ``` ## See Also - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) - [Creating a Secrets Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task) - [Build an HTTPS Service](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) --- product: API Manager version: 2.x is-latest-version: true --- # Build RAML or OAS API Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager 2.x enables you to use a RAML or OAS type of API Proxy, for all your Mule 4 based proxies. ## Configuring your RAML or OAS API Proxy Configure your RAML or OAS API proxy by completing the following steps: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Add new API**. 3. Select **Mule Gateway** as your runtime. 4. Select **Deploy a proxy application** for **Proxy type**. 5. If you selected to deploy a proxy application, select the **Target type** from the following options: - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores by default. 1. Select a space. To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. 1. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 2. Enter a **Proxy app name**. - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an on-premises server that is registered in Runtime Manager. See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more information. 1. Select a target from the list or click **Add server**. 2. Enter a **Proxy app name**. - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API proxy to a Mule runtime instance running on an on-premises server that is not registered in Runtime Manager. For more information, see [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model). Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). . [Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises). - **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime engine that is managed on Runtime Fabric. See [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric) for more information. 1. Select a target from the list. 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. 1. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select **REST API** as the **Asset type**. 3. Upload either a RAML or OAS file for your REST API. > [!NOTE] Anypoint API Manager supports OpenAPI Specification (OAS) 3.0 and 3.1, with the > exception of the callback feature. To work around this issue, handle the callback outside of > the Mule runtime engine domain or use an OAS 3.0 or 3.1 specification that does not use > callbacks. 4. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 5. View the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances) 1. Click **Next**. 2. Configure the downstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

3. Click **Next**. 4. Configure the upstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

5. Click **Next**. 6. Review your selections and edit them if necessary. 7. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. ## See Also - [Reviewing API Proxy Benefits and Impacts](https://docs.mulesoft.com/api-manager/latest/proxy-advantages) - [Build an HTTPS Service](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) - [Deploying an API Proxy](https://docs.mulesoft.com/api-manager/latest/proxy-latest-concept) --- product: API Manager version: 2.x is-latest-version: true --- # Build SOAP API Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager 2.x enables you to use SOAP API proxies for your SOAP-based web services. The SOAP proxy requires a WSDL definition that describes the backend service. The WSDL defines how the API proxy must perform validations on incoming requests and correctly routes outbound requests for the corresponding API endpoint. ## SOAP Proxy Schema Validation Regardless of whether validation is enabled for an API, the SOAP request validator always verifies the following: - The incoming request has a valid SOAP action. - The payload is a valid SOAP envelope. If validation is enabled for an API, the SOAP request validator also verifies that the content of the `body` tag matches the one defined in the WSDL. The SOAP action in the inbound request is matched against the same-named operation in the WSDL. The proxy then validates that the namespace URI of the element and the name associated with the operation match the same details in the incoming request. If the validation fails, an error message informing the expected namespace URI and element name is generated. If the SOAP action in the inbound request is empty, the application then attempts to match the namespace URI and element name of the incoming request element to all the operations defined in the WSDL. The first operation that matches the incoming request determines whether the validation is successful. If the match fails, an error message is generated with the suggested tag names for the element in the request. ## Retrieving the WSDL from the Proxy Application The SOAP proxy allows the backend web service to post requests (POST) and to retrieve (GET) the service WSDL. The GET request is performed by an HTTP GET method with either `wsdl` or `WSDL` as the query parameter: - `[http://my-proxy-url:myProxyPort?wsdl](http://my-proxy-url:myProxyPort?wsdl)` - `[http://my-proxy-url:myProxyPort?WSDL](http://my-proxy-url:myProxyPort?WSDL)` ## Configuring a WSDL from Remote Location Using Basic Authentication Credentials You can access a protected WSDL that is hosted on a remote location by configuring the `basic.auth.user` and `basic.auth.password` application properties in the `basicauth.properties` configuration file. The properties are then passed to the validator module: ```xml ``` If you do not provide authentication values for the properties, the WSDL is retrieved unauthenticated. ## Retrieving a WSDL Using TLS With SOAP proxy v2.1.0, you can retrieve a WSDL from a remote location using the TLS context configuration by default. The TLS context used for this operation is the same as the outbound configuration of the proxy. ## Configure Your SOAP Proxy Configure your SOAP proxy by completing the following steps: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Add new API**. 3. Select **Mule Gateway** as your runtime. 4. Select **Deploy a proxy application** for **Proxy type**. 5. If you selected to deploy a proxy application, select the **Target type** from the following options: - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores by default. 1. Select a space. To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. 1. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 2. Enter a **Proxy app name**. - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an on-premises server that is registered in Runtime Manager. See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more information. 1. Select a target from the list or click **Add server**. 2. Enter a **Proxy app name**. - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API proxy to a Mule runtime instance running on an on-premises server that is not registered in Runtime Manager. For more information, see [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model). Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). . [Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises). - **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime engine that is managed on Runtime Fabric. See [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric) for more information. 1. Select a target from the list. 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. 1. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select **SOAP API** as the **Asset type**. 3. Select either **Upload a WSDL** or **Use an external link** as the method. 4. Update the **Asset type**, **API version**, and **Asset version** if needed. 1. Click **Next**. 2. Configure the downstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

3. Click **Next**. 4. Configure the upstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

5. Click **Next**. 6. Review your selections and edit them if necessary. 7. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. ## Troubleshooting SOAP Proxies for Missing Imports on XSD Files A SOAP proxy can fail during deployment due to an incorrect WSDL definition. For example, the following error indicates missing imports in one of the XSD files that are a part of the WSDL: ```text org.xml.sax.SAXParseException; systemId: http://localhost:8080/?wsdl304785538; lineNumber: 2; columnNumber: 52; src-resolve.4.2: Error resolving component 'myNamespace:myElement’. It was detected that 'myNamespace:myElement' is in namespace 'http://my.namespace.url', but components from this namespace are not referenceable from schema document 'http://localhost:8080/?wsdl304785538'. If this is the incorrect namespace, perhaps the prefix of 'myNamespace:myElement' needs to be changed. If this is the correct namespace, then an appropriate 'import' tag should be added to 'http://localhost:8080/?wsdl304785538'. ``` This issue occurs when the definition of an element that is used in the WSDL file is found in an external XSD with a namespace other than that of the current WSDL file. You can resolve this issue by adding the appropriate imports in the WSDL file. For example, for the exception in the previous example, the WSDL file must contain the following import in the `types` element: ```text ``` ## See Also - [API Proxy](https://docs.mulesoft.com/api-manager/latest/api-proxy-landing-page) - [Creating an API Instance by Importing from Exchange](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) - [Configure TLS Context for an API](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) --- product: API Manager version: 2.x is-latest-version: true --- # Classifying an API Instance into an Environment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you upgrade to API Manager 2.x your APIs are placed in an unclassified environment. You need to classify unclassified APIs to govern or otherwise manage the APIs. Even though API Manager supports tracking APIs with both organization and environment credentials, MuleSoft recommends using environment credentials since the permissions associated to them are more restrictive. You need to restart Mule Runtime after changing credentials. Restarting can cause downtime. See [Configuring Mule Servers with Environment Credentials (Advanced Classification: Optional)](#configuring-mule-servers-with-environment-credentials-advanced-classification-optional) below for details on how to change them. After doing so, you may classify your API to an environment that API Manager will suggest. Using credentials from one environment does not allow: - Tracking APIs from different environment - Tracking APIs from different organizations If you need to track APIs in either of these ways, use organization credentials. See [Configuring Organization Credentials in Mule Runtime 4](https://docs.mulesoft.com/mule-gateway/mule-gateway-org-credentials-mule4). If you need to track APIs using environment credentials review the advanced section. ## Classifying the API Instance on API Manager 1. In API Manager, click the environment control, which is labeled SANDBOX in this example: ![API Manager API Administration with the environment sandbox selected.](/mulesoft/current/en-us/api-manager/latest/_images/environment3.png) If you do not have a suitable environment you want to classify the API into, create the environment in Access Management. See [To Create a New Environment](https://docs.mulesoft.com/access-management/environments#to-create-a-new-environment) and [Reviewing Environment Concepts](https://docs.mulesoft.com/api-manager/latest/environments-concept) for more information. 2. Select **Unclassified**. ![The Switch Environment dialog showing the environments.](/mulesoft/current/en-us/api-manager/latest/_images/switch-environment.png) 3. Click **Switch**. A list of unclassified APIs appears. ![API Administration dialog box showing a list of unclassified APIs.](/mulesoft/current/en-us/api-manager/latest/_images/classify.png) 4. If the **Classify** button is disabled, click **Reconnect** to link the unclassified API with its corresponding Exchange asset. ![Reconnect option that enables the Classify action for an unclassified API.](/mulesoft/current/en-us/api-manager/latest/_images/reconnect-api.png) Once the API is successfully reconnected, the **Classify** button becomes available. 5. Click **Classify**. 6. For **Target environment**, select the environment for the API from the list of environments available to you. For example, select **Test**. 7. For **Instance name**, optionally type a unique instance name. For example, type `abc-api-1`. For environments, APIs can have more than a single instance. Therefore, an instance name is required to uniquely identify it. ![The Classify dialog box with example values in the Target environments and instance name fields.](/mulesoft/current/en-us/api-manager/latest/_images/classify-instance.png) ## Classifying the API Instance via REST API You can also classify unclassified APIs using the Anypoint Platform REST APIs. This method is useful for automation, scripting, or bulk updates. > [!NOTE] Customers can continue using the REST APIs for classifying API instances after January > 31, 2026. These endpoints remain available and supported for automation, scripting, and > operational workflows. Before you begin, obtain an authentication token using the Login API. ### Logging In POST `/accounts/login` Payload example: ```json { "username": "myusername", "password": "mypassword" } ``` Curl example: ```bash curl --location 'https://anypoint.mulesoft.com/accounts/login' \ -H 'Content-Type: application/json' \ --data-raw '{"username":"myusername","password":"mypassword"}' ``` The response contains the bearer token you must use in subsequent requests. ### Getting the List of Unclassified APIs Use this request to retrieve all API instances that are not yet classified into an environment. GET `/apiplatform/repository/v2/organizations/{organizationId}/apis` Example: ```bash curl --location 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations/00000000-0000-0000-0000-00000000000/apis' \ --header 'Authorization: bearer ' ``` ### Classifying an Unclassified API Once you identify the API and version you want to classify, send the classification request. POST `/apiplatform/repository/v2/organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}/classify` Payload: ```json { "environmentId": "00000000-0000-0000-0000-00000000000", "instanceLabel": "mylabel" } ``` Curl example: ```bash curl --location 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations/00000000-0000-0000-0000-00000000000/apis/0000000/versions/0000000/classify' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data '{"environmentId": "00000000-0000-0000-0000-00000000000","instanceLabel": "mylabel"}' ``` Notes: - `environmentId` is required. - `instanceLabel` is optional. - Existing client contracts continue to work after classification. ### Connecting the API to an Exchange Asset An unclassified API must be linked to an asset in Exchange and must have an endpoint configured. To associate the API with an Exchange asset, update the GAV coordinates using the following calls. #### Update the API Root Object PATCH `/apiplatform/repository/v2/organizations/{organizationId}/apis/{apiId}` Payload: ```json { "groupId": "{groupId}", "assetId": "{assetId}" } ``` #### Update the API Version PATCH `/apiplatform/repository/v2/organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}` Payload: ```json { "assetVersion": "{assetVersion}" } ``` Reference: Exchange Experience API [https://dev-portal.mulesoft.com/apis/exchange-experience.html](https://dev-portal.mulesoft.com/apis/exchange-experience.html) ### Deleting an Unclassified API You can delete an unclassified API using: DELETE `/apiplatform/repository/v2/organizations/{organizationId}/apis/{apiId}` Example: ```bash curl --location --request DELETE 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations/00000000-0000-0000-0000-00000000000/apis/0000000' \ --header 'Authorization: bearer ' ``` If the API has existing contracts in **pending** or **approved** state, revoke them before deletion: POST `/apiplatform/repository/v2/organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}/contracts/{contractId}/revoke` You can obtain `contractId` via: GET `/apiplatform/repository/v2/organizations/{organizationId}/applications/{applicationId}/contracts` ### API Analytics Impact In the Pre-Crowd version of API Manager, all dashboards were organization-wide. In Crowd, each dashboard links to a particular environment. If you had custom reports for your APIs before migrating, those custom reports would no longer work after you classify all your APIs. ### Configuring Mule Servers with Environment Credentials (Advanced Classification: Optional) You can use this configuration to track APIs that use environment credentials. This configuration requires a server restart. The sections that follow help you classify your APIs depending on how you deployed proxies before migration. ### Managing an API instance by using a Proxy deployed through API Manager If your API was deployed in Runtime Manager: 1. From API Administration, click the **API Name** of the API instance. 2. Click **Runtime & Endpoint Configuration > Save & Deploy**. 3. Select the **Runtime version**. 4. Click **Save & Apply**. If your API was deployed in an on-premises standalone runtime: 1. From API Administration, click the **API Name** of the API instance. 2. Click **Runtime & Endpoint Configuration > Save & Deploy**. 3. Specify a runtime version for Mule Agent 1.9 and later. 4. Click **Save & Apply**. To update an existing server: 1. Use SSH to access the standalone runtime server. 2. Download the Runtime Agent 1.9 or later. 3. Update the Gateway runtime agent. 4. Restart the Gateway. ### Managing an API instance by using a Basic Endpoint or a Proxy deployed through Runtime Manager If your API was deployed in Runtime Manager: 1. Navigate to Access Manager. 2. Click Environments. 3. Click the environment name you want to use. 4. Copy the Client ID and Client Secret. To update an application in Runtime Manager: 1. Navigate to the proxy application in Runtime Manager. 2. Click Settings. 3. Click Properties. 4. Change the values of the following properties to the values from the Environment: - Anypoint.platform.client\_id - Anypoint.platform.client\_secret 5. Click Apply changes. To update an application deployed in standalone Mule Runtime: 1. Use SSH to access the standalone runtime server where the application is deployed. 2. Download Runtime Agent 1.9.x. 3. Update the Runtime Agent. 4. Restart the Mule Runtime. ### Other Deployments This section explains the manual steps needed to prepare Mule Runtime to use API environments without updating the agent or registering the server with Runtime Manager. Getting the environment client ID and secret: 1. Navigate to Access Manager. 2. Click Environments. 3. Click the environment name that you want to use. 4. Copy the Client ID and Client Secret. Updating an application in Runtime Manager: 1. Navigate to the proxy application in Runtime Manager. 2. Click Settings. 3. Click Properties. 4. Change the values of the following properties to the values from the environment: - anypoint.platform.client\_id - anypoint.platform.client\_secret Updating standalone runtimes: 1. Use SSH to access the runtime server that you want to update. 2. Edit the `//wrapper.conf` file. 3. Change the values of the following properties to the values from the environment: - anypoint.platform.client\_id - anypoint.platform.client\_secret 4. Restart Mule Runtime. ## See Also - [To Shutdown, Restart and Delete a Server (Hybrid)](https://docs.mulesoft.com/runtime-manager/servers-actions) --- product: API Manager version: 2.x is-latest-version: true keywords: contract, register, client, application, secret, credential, instance --- # Client Applications, Contracts, and Credentials > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Credentials consist of two keys: the client ID and the client secret. Anypoint API Manager (API Manager) uses the following types of credentials: - Client application - Organization - Basic Authentication policy - SOAP proxy ## Client Application Credentials As the Organization Administrator, after you grant access to applications in Anypoint Exchange (Exchange), a contract is automatically created between the instance and the application. The contract gives access to the application based on SLA tiers that you might specify. Only one contract can exist per instance and application at any time. As a user, when you request access to an asset from Exchange, your request is automatically approved if no SLA tiers are defined. If the asset includes an SLA tier, you can either configure your request so that it is automatically approved despite the SLA tier, or you can request approval manually. Client application credentials are generated when you create a new application and request access to an instance. Requests must include these credentials if the instance is protected by a client ID enforcement policy. Organization Administrators can configure this enforcement policy to accept credentials either as headers or as query parameters, although using headers is more secure. For additional information about client application credentials, see: - [Request Access to an Instance](https://docs.mulesoft.com/exchange/to-request-access). - [View Instance Contracts](https://docs.mulesoft.com/api-manager/latest/view-api-contracts). - [Grant Access to Requests](https://docs.mulesoft.com/api-manager/latest/manage-client-apps-latest-task). - [Remove Instance Contracts](https://docs.mulesoft.com/api-manager/latest/remove-client-app-latest-task). - [Obtain the Credentials of a Registered Client Application](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task). Default policies that internally enforce client application credentials include: - [Rate-Limiting SLA](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [Mule OAuth 2.0 Access Token Enforcement](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement) (Mule v3.8.5 or later) - [PingFederate OAuth 2.0 Token Enforcement](https://docs.mulesoft.com/mule-gateway/policies-included-pingfederate-oauth-token-enforcement) (Mule v3.8.5 or later) - [OpenID Connect OAuth 2.0 Token Enforcement](https://docs.mulesoft.com/gateway/latest/policies-included-openid-token-enforcement) (Mule v3.8.5 or later) - [JWT Validation](https://docs.mulesoft.com/gateway/latest/policies-included-jwt-validation) (Mule v3.8.5 or later) For information about how to configure and apply client ID enforcement policies, see [Client ID Enforcement Policy](https://docs.mulesoft.com/gateway/latest/policies-included-client-id-enforcement). ## Organization Credentials Organization credentials provide a method to uniquely identify a specific environment, an organization, or a business group when linking Mule runtime engine (Mule) to an organization using Anypoint Platform. Mule uses these credentials to connect to and access your organization. For example, you use environment credentials to connect a local Anypoint Studio (Studio) Mule deployment to API Manager through Autodiscovery. This connection allows the Studio-deployed application to be managed by API Manager. See [Review Environment Concepts](https://docs.mulesoft.com/api-manager/latest/environments-concept) and [Autodiscovery](https://docs.mulesoft.com/mule-gateway/mule-gateway-autodiscovery-overview). For additional information about configuring and obtaining organization credentials, see [Configuring Organization Credentials in Mule Runtime 4](https://docs.mulesoft.com/mule-gateway/mule-gateway-org-credentials-mule4). ## Basic Authentication Policy Credentials The Simple Authentication default policy protects an instance by forcing requests to provide credentials. These credentials populate a request’s `Authorization` header. For details on building requests using the Simple Authentication policy, see [Basic Authentication: Simple Policy](https://docs.mulesoft.com/gateway/latest/policies-included-basic-auth-simple). The Lightweight Directory Access Protocol (LDAP) Authentication default policy restricts access by using an LDAP authentication mechanism. LDAP authentication forces requests to provide credentials in an `Authorization` header and then requests the configured LDAP instance to determine if the credentials are correct in the provided LDAP context. For details on configuring the LDAP Authentication policy, see [Basic Authentication: LDAP Policy](https://docs.mulesoft.com/gateway/latest/policies-included-basic-auth-ldap). ## SOAP Proxy Credentials You can protect a WSDL that is hosted on a remote location by configuring basic authentication credentials. For details on building a SOAP proxy, see [Build SOAP Proxies](https://docs.mulesoft.com/api-manager/latest/building-soap-proxy). --- product: API Manager version: 2.x is-latest-version: true keywords: hashing, client credentials, auto-generated, raml, wsdl, apikit, http --- # Configure Credentials Hashing for Mule 4 > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Enable hashing of your client credentials to add another layer of security for your APIs by hiding the client secrets from the Mule runtime engine (Mule) server. When you enable client hashing, Mule Gateway stores the client credentials in memory, with only the client secret hashed. Additionally, if you enabled both encryption and hashing in Mule Gateway, the contract information in memory is hashed, but not encrypted. When client hashing (disabled by default) is enabled, it uses the SHA-256 hashing algorithm. If you modify the configuration to enable or disable hashing in Mule Gateway and then restart your Mule server to apply the updated configuration, your incoming requests are not affected and they continue to be processed normally. ## How Client Credential Hashing Works With client credential hashing enabled, when a request is received, Mule Gateway obtains the client secret from the client credentials of that request and hashes it. Mule Gateway then compares and verifies the client ID and the hashed client secret from the request with the credentials stored in memory before passing the request to Mule. ## Configure Client Credential Hashing To enable client hashing, start the Mule server with the `anypoint.platform.hash_clients` property enabled. You can enable the property by either running the `start` command or by configuring the property in the `wrapper.conf` file in the `conf` directory: - `start` command: `$MULE_HOME/bin/mule start -M-Danypoint.platform.hash_clients=true` - `wrapper.conf` property: `wrapper.java.additional.=-Danypoint.platform.hash_clients=true` If you add the `wrapper.java.additional.n` entries to the configuration file, ensure that each instance of `` is a consecutive number. Otherwise, Java does not parse the properties correctly. For example: - Incorrect usage `wrapper.java.additional.300=-Danypoint.platform.hash_clients=true` `wrapper.java.additional.300=-Dsome.other.property` - Correct usage: `wrapper.java.additional.300=-Danypoint.platform.hash_clients=true` `wrapper.java.additional.301=-Dsome.other.property` ## Verify Client Credential Hashing To verify that Mule Gateway started with client hashing enabled, add the following entry in the Log4j logger configuration: `` The log4j file is present in `$MULE_HOME/conf/log4j2.xml`. If hashing is enabled, the Mule environment displays the following message when deploying the first API: `API Gateway initializing with Client Hashing algorithm: SHA-256` --- product: API Manager version: 2.x is-latest-version: true keywords: client providers, external client providers, identity providers --- # Configure Multiple Client Providers for Client Management > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use multiple client providers, to help you enforce security and regulations in your business organization. These client providers, such as, OpenAM and PingFederate, enable you to secure your operational data, such as client credentials and access tokens. You can use an Anypoint Platform native client provider (default), configure an external client provider, or use both the Anypoint Platform native client provider with the external client provider. To assign separate client providers for different organizations and environments, you must first enable client applications to be authorized using OAuth for the client providers that you want to implement in your organization. API Manager 2.2.14 introduces multiple client identity provider (IdP) support, enabling your environment to use either the default Anypoint Platform native client IdP or one or more external client IdPs. You use multiple client providers for: - Different environments, such as production, QA, and sandbox - Internal and external APIs > [!NOTE] Even if a client provider is configured for internal APIs, it must be accessible from > the public internet so that it can communicate with Anypoint Platform. ## How Using Multiple External Client Providers Works When you enable external client providers, they act as authorization servers to issue tokens that enable client applications to access an API. When you request access to that API, the corresponding client ID and client secret are created in the IdP specified in that API specification. If an API applies the Client ID Enforcement policy but not the OAuth policy, the client application is still created in an external client provider. When an OAuth policy is deployed to the API gateway, the platform automatically injects IdP configuration (such as the token URL and token introspection URL) to the policy. If no external IdPs are enabled, Access Manager acts as the default authorization server in that case. ## The Use Case To better understand how to implement multiple external client providers, imagine a company named "Good Weather" that uses meteorology to forecast changing weather. Good Weather collects quantitative data about the current state of the atmosphere at a given place and, using meteorology, predicts how that current state will change over time. Good Weather has several sub-organizations running under the root organization. These sub-organizations exist based on the functions they perform, for example, Engineering and Forecasting. The Forecasting department researches and collects recent meterological data from various sources. This data is then consumed by various client applications. While the Engineering department maintains the applications that host the forecasting research data. Because Good Weather must ensure that its weather-forecasting data is accurate and secure, the weather APIs are accessed only by employees of the Forecasting department. Good Weather also wants to ensure that the production APIs are the single source of truth at all times. To ensure security and access segregation for different organizations, environments, and APIs, Good Weather IT sets up separate external client providers for the Forecasting department. ## Onboarding Multiple Client Providers The procedure that you use to onboard multiple client providers differs based on how you have configured client providers and the business organizations in your company: - No external client providers configured Creating and modifying such environments and APIs involves the same steps as before. The native Anypoint Platform client provider is assigned for such environments. The existing APIs and environment have no impact. - External client providers configured If you have external client providers such as PingFederate configured for your environments, the client provider is automatically ported when you onboard the multiple client providers feature. However, when you create a new environment, you must manually assign the correct client provider to your environment in Access Management. **Best Practice** To secure your APIs, create one external client provider per environment. Assign the existing client provider to your production environment and add the new providers to QA and to other environments, such as the sandbox. However, check the possible impact on managed APIs and their consumers. Avoid using the same IdP in production and nonproduction environments. You can use the same IdP in multiple production environments or in multiple nonproduction environments. If you configure multiple client providers, both the native Anypoint Platform client provider and any external client providers can be used in the same environment. Before implementing multiple client providers, see the [guidelines](#guidelines). ## Guidelines for Implementing Multiple Client Providers Before you implement multiple client providers in Anypoint Platform, carefully review and understand the following points: - You cannot change a client provider’s existing API instance when that API: - Has contracts - Has client provider-related policies applied, such as PingFederate and OpenID policies (one exception is when the client provider type remains unchanged) - Belongs to an API group - If you previously did not assign an external client provider to an environment when promoting and importing an API, API Manager 2.2.14 and later uses the native provider by default. You can then reassign the appropriate external client provider for that API. - If you assign an external client provider to an environment that was previously using a native provider: - Existing APIs in that environment continue to use the native Anypoint Platform client provider. - New APIs use the new external IdP. - You can use either the default native Anypoint Platform client provider and one or more external client providers. There is no need to disable an external provider to use the native Anypoint Platform provider. - If you remove a client provider from an environment, all existing APIs and client applications using that client provider continue to work. - If you delete a client provider from the root organization, all existing APIs and client applications using that client provider default to the native Anypoint Platform client provider. Even though contracts remain intact, policies that authorize against that provider fail because the configuration is deleted. ## Tasks for Implementing Multiple Client Providers Based on Roles Based on your role and the needs of your organization, you might perform the following tasks to implement multiple client providers:
TaskRoleWhere to PerformNotes

Assign multiple IdPs, including a default, to an environment.

Business Group Administrator

Access Management

Using multiple IdPs provides flexibility to choose an IdP in API configuration inside API Manager, which can be useful when multiple teams are using the same environment for building APIs, but still want to use separate IdPs. This also helps in use cases when separate API instances are created for internal and external consumers, and separate IdPs based on a consumer is required.

Receive notification about possible interruption to API consumers before changing IdP configuration.

Business Group Administrator

Access Management

None

Review to which client provider an application belongs on the client administrator page to be able to differentiate between different applications with the same name.

API Manager Administrator

Access Management

None

Configure an API in API Manager to automatically map to a default IdP configured by the business group administrator. The owner can also select a different IdP, if available.

API owner

API manager

None

When promoting or importing an API from one environment to another, specify an IdP from the target environment.

API owner

API manager

If there is just one (default) IdP specified for the target environment, it is automatically assigned to the API.

Request access to an API based on the API instance that exists in a specific environment.

Application User

Exchange

When you select the API for which you want to request access, you must first choose the API instance to which you are requesting access. The API instance is filtered based on the environment.

## Configuring Multiple Client Providers User Flow Returning to the Good Weather use case, imagine that the company uses the following flow to implement multiple external client providers in their organization: ![User Flow for Configuring Multiple External Client Providers](/mulesoft/current/en-us/api-manager/latest/_images/multiple-IdP-user-flow.png) As shown in the diagram, you first configure your external client provider and assign it to the appropriate environments. When you create or modify an API within a specific environment, the new client provider is displayed. You can reselect the appropriate client provider. When promoting an API from one environment to another, prevent policy mismatches by doing either of the following: - Use the same client provider type (for example, PingFederate or OpenAm) in both environments. - Or, delete every client provider-related policy applied to the promoted API. As an API consumer, you can request access to an API based on the API instance in a specific environment. ## Configure Multiple Client Providers To configure multiple external client providers: 1. From **Access Management**, first enable [client management](https://docs.mulesoft.com/access-management/managing-api-clients). As an Anypoint Administrator, you must first enable client applications to be authorized using OAuth for the client providers to be implemented in the organization. 2. From **Access Management**, [assign client providers](https://docs.mulesoft.com/access-management/environments#add-an-idp-to-an-existing-environment) to environments. As an Anypoint Administrator, configure a client provider and assign it to specific environments. 3. From **API Manager**, [create or modify](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) APIs using the new IdPs. As an API owner, create an API, import an API from Anypoint Exchange, or modify an API in API Manager. Optionally, either promote an API from one environment to another or import or export an API as described earlier. 4. From **API Manager**, [configure policies](https://docs.mulesoft.com/gateway/latest/policies-automated-overview). As an API Manager Administrator, you can apply policies to an API based on the client provider associated with it. 5. From **Exchange**, [request access](https://docs.mulesoft.com/exchange/to-request-access) to an API instance within a specific environment for business organization. As an API consumer, you can request access to an API instance from registered client applications using private Exchange or public portals. ## See Also - [Adding a Mule Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) - [Client Management in Anypoint Platform](https://docs.mulesoft.com/access-management/managing-api-clients) - [Add API Instances](https://docs.mulesoft.com/api-manager/latest/add-api-instances) - [Exporting an API Instance on API Manager](https://docs.mulesoft.com/api-manager/latest/export-api-latest-task) - [Promoting an API Instance to Another Environment](https://docs.mulesoft.com/api-manager/latest/promote-api-task) --- product: API Manager version: 2.x is-latest-version: true --- # Configure OAuth 2.0 Provider in Mule > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule OAuth 2.0 Provider is an OAuth 2.0 provider alternative developed by MuleSoft that can be used in any MuleSoft API Platform organization, including federated ones. The provider enables secure authentication and authorization for APIs across different environments and organizational structures. Use this provider to implement OAuth 2.0 flows, manage access tokens, and control API access permissions. It supports both single-tenant and multi-tenant deployments, making it suitable for various enterprise scenarios. You must deploy Mule OAuth 2.0 Provider to a runtime with API gateway capabilities, for example, Mule runtime engine (Mule) 3.x, 4.2.0, or later, with the corresponding organization credentials. The following third party OAuth 2.0 providers are supported: - PingFederate - OpenAM - OAuth 2.0 providers supporting Open ID Connect The [Mule OAuth 2.0 Access Token Enforcement policy](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement) is designed to work with Mule OAuth 2.0 Provider. ## Downloading Mule OAuth 2.0 Provider You can download Mule OAuth 2.0 Provider from Anypoint Exchange. See [Mule OAuth 2.0 server for Anypoint Platform](https://anypoint.mulesoft.com/exchange/org.mule.templates/api-gateway-oauth2-provider/). This feature is available in Mule 4.2.0 and later. ## OAuth 2.0 Dance The authentication performed by the OAuth 2.0 provider, API, and client application conforms to RFC 6749. This authentication process is known as the [OAuth 2.0 dance](https://docs.mulesoft.com/api-manager/latest/oauth-dance-about). Mule OAuth 2.0 Provider supports all [grant types](https://docs.mulesoft.com/api-manager/latest/oauth-grant-types-about). The entity that requests access to a resource protected by the Mule OAuth 2.0 Access Token Enforcement policy is a `Client`. ### Endpoints You can call the following Mule OAuth 2.0 Provider endpoints in your API implementation: ![mule oauth provider](/mulesoft/current/en-us/api-manager/latest/_images/mule-oauth-provider.png)
PurposeDefault PathDescription

Token validation

/validate

Used to verify the validity of the token: whether the token is expired, revoked or fake. You can define more than one validation endpoint, each of them enforcing different scopes. For more information, see <Scopes>.

Authorization

/authorize

Used to obtain a token when the client is running in a browser using a scripting language or when the client is a web server.

Access

/access_token

Used when the client is owned by the same entity as Mule OAuth 2.0 Provider or when the client is the same entity as the protected resource owner.

Token revocation

/revoke

[Optional] Used to revoke a valid token to render it invalid.

### Implementing Scopes The OAuth 2.0 [scopes](https://datatracker.ietf.org/doc/html/rfc6749#page-23) enable you to further limit access to a resource protected by OAuth. You can define words, such as `READ` and `WRITE`, or others specific to your organization, such as `CONTRACTOR`, `PUBLIC`, `EMPLOYEES_ONLY`, and so on. You can define scopes in three different places: - In the universal set definition, `defaultScopes`, where you define all possible scopes: ```xml ... ``` - In the `/validate` validation endpoint, to enforce a particular subset of the previously defined scopes. - In the Mule OAuth 2.0 Access Token Enforcement policy, where you can enforce scopes by specifying a space-separated list. Specifying more than one scope enforces the `AND` logic. If the token to be validated is associated with all of the requested scopes, the policy validates the token successfully. Example of using scopes in Mule 4.2.x or later: ```xml ... ... ``` For complete information, see [Mule OAuth 2.0 Server for Anypoint Platform](https://anypoint.mulesoft.com/exchange/org.mule.templates/api-gateway-oauth2-provider/). ## Client Application Cache To prevent any possible downtime of Mule OAuth 2.0 Provider due to errors when connecting to Anypoint Platform, the Mule OAuth client store caches each valid client application for which a token is requested. In the rare instance that the provider requests a new token when there is no connection available, the client store falls back to cache. The entries expire in 30 days, which is the default setting. To ensure service availability in case of a restart or lack of connection to Anypoint Platform, you can configure this range to persist the cache locally. In case a client application for which a token already exists in the client store is removed from Anypoint Platform, the client store removes the client from the cache on the next token request, mirroring the platform status. The mechanism that caches the result of a successful token validation is part of the [Mule OAuth 2.0 Access Token Enforcement policy](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement). ### Customizing the Client Application Cache Mechanism You can customize the default values of the cache mechanism in Mule 4.2.0 and later. The object store has two configurable properties:
Property NameDefinition

anypoint.oauth_provider.cache_persistence_enabled

Defines whether the caching mechanism must persist locally. The default value is true if the property is not set or cannot be parsed. Cache persistence allows client authorization without connection to Anypoint Platform.

anypoint.oauth_provider.cache_ttl_days

Represents how many days each client application must be cached by the OAuth Server. You can specify any positive floating-point number for this value. The default value is 30, representing 30 days.

## See Also - [Mule OAuth 2.0 Access Token Policy Usage](https://docs.mulesoft.com/mule-gateway/policies-included-oauth-access-token-enforcement) - [OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement](https://docs.mulesoft.com/api-manager/latest/oauth-dance-about) - [OAuth 2.0 Grant Types](https://docs.mulesoft.com/api-manager/latest/oauth-grant-types-about) - [Configuring Organization Credentials in Mule Runtime 4](https://docs.mulesoft.com/mule-gateway/mule-gateway-org-credentials-mule4) --- product: API Manager version: 2.x is-latest-version: true keywords: proxy, api, auto-generated, raml, wsdl, apikit, http --- # Configure Proxies for Your APIs > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Protect your APIs or web services against attacks by using API proxies, which function as intermediaries between the external applications and the backend server. The API proxy is agnostic to your backend’s location and programming language. Additionally, your backend can be a non-Mule application. When you deploy an API proxy in front of your API, the proxy adopts API gateway capabilities to secure the API by using different types of [policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis). Anypoint Platform enables you to deploy the proxy application directly to CloudHub or Anypoint Runtime Fabric. Your proxy application is then automatically tracked by API Manager. API Manager automatically generates the proxy application when you configure your API as an endpoint with a proxy and includes an API Autodiscovery feature in the application. Mule locks the API until all policies have been applied. The client application (consumer) calls the proxy, which then forwards the call to the API. After you deploy the application, the Mule instance calls API Manager using the client ID and secret to obtain the policies for the API. ## When to Use API Proxies You can use API proxies: - If your API is live, but not yet hosted in a Mule runtime engine (Mule) server - If you already have a Mule application, but can’t use [API Autodiscovery](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4) because you have a closed-code backend API - If you want to perform schema validation on every incoming request for a RAML, OAS, or SOAP API Depending on the type of specification you used to create your API, you can apply one of the following API proxies: - HTTP or [HTTPS](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) - [WSDL](https://docs.mulesoft.com/api-manager/latest/building-soap-proxy) - [RAML or OAS](https://docs.mulesoft.com/api-manager/latest/proxy-deploy-raml-oas-proxy) ## How API Proxies Work The API proxy intercepts incoming API requests, and can provide authentication, rate limiting, request and response transformation, and logging features. When a client application sends a request to your backend API, the request is first intercepted by the API proxy. The proxy applies policies for the requested backend API, and the policies determine whether, and how, to forward the request to your backend API. If a policy fails any of the validations, the API proxy returns an error response (appropriate to the failed policy) and the request does not reach your backend. If all the policy validations and actions are successful, the proxy forwards the (possibly transformed) request to your backend API. The API proxy then intercepts the response from your backend, applies any relevant policies to the response, and then returns the (possibly transformed) API response to the client application. ## API Proxy Advantages API proxies improve team performance and backend API security, and validate incoming requests using policies. The API proxies: - Increases engineering bandwidth You can deploy a proxy directly to a [Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/), [CloudHub](https://docs.mulesoft.com/cloudhub/), [Hybrid](https://docs.mulesoft.com/runtime-manager/deployment-strategies#hybrid-deployments.adoc), or [standalone Mule](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model) instance with just a few clicks. Even if you don’t know how to create a Mule application, API Manager builds and configures it using API Autodiscovery, so your API can be automatically tracked by API Manager after the deployment has completed. - Enables customization In most cases, the proxy generated in API Manager is suitable for deployment. However, in the Mule environment, you can use [Anypoint Studio](https://docs.mulesoft.com/studio/import-export-packages) to edit the proxy to meet custom requirements. - Secures and governs your APIs using policies and [Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/viewing-api-analytics) The proxy enables you to protect your API with the full capabilities of the API gateway, including access to Mule API Analytics. - Implements validations Most proxies, including RAML, REST, and WSDL proxies, enable you to perform validations on all incoming requests, using your API definition. You can choose different levels of validation, depending on your requirements: - Regular validations Compare the payload, query parameters, URI parameters, headers, and form parameters with the schema defined in your API specification. When using this configuration, the unspecified query parameters and headers in the API specification are also sent to the backend service. - Strict validations Accept only those requests, parameters, and headers that are explicitly defined in your API specification, thereby ensuring security of your APIs by controlling the parameters that the backend receives. ## See Also - [Downloading an API Proxy](https://docs.mulesoft.com/api-manager/latest/download-proxy-task) - [Deploying an API Proxy](https://docs.mulesoft.com/api-manager/latest/proxy-latest-concept) - [Handling API Proxy Status Codes](https://docs.mulesoft.com/api-manager/latest/wsdl-raml-http-proxy-reference) --- product: API Manager version: 2.x is-latest-version: true --- # Configure REST Validator Extension > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The REST validator extension enables you to perform schema validations that use a RAML or OAS specification against the attributes of a request. Additionally, the extension adds default values to attributes, if they are already not set in the request. Unless otherwise noted, this documentation applies only to REST validator extension v2.x. To use the REST validator extension in your Mule artifact, such as a Mule runtime engine (Mule) application XML, you must: 1. [Include the dependency in your pom.xml file](#include-dependency). 2. [Add the namespace and schema to your Mule artifact](#add-namespace-and-schema). 3. [Configure the REST validator extension](#configure-rest-validator-extension). 4. [Use REST validator operations](#use-operations). ## Include Dependencies in Your pom.xml File You can include the REST validator in your Mule artifact (for example, Mule application XML) by adding the following snippet in the `` section of your `pom.xml` file: ```XML com.mulesoft.anypoint mule-rest-validator-extension ${restValidatorVersion} mule-plugin ``` As a best practice, define a Maven property inside the `` section, with the version of the REST validator that you want to use: ```XML 2.3.2 ``` ## Add Namespace and Schema to Your Mule Artifact To use the REST validator operations in your Mule artifact, include the following namespace and schema: ```text xmlns:rest-validator="http://www.mulesoft.org/schema/mule/rest-validator" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/rest-validator http://www.mulesoft.org/schema/mule/rest-validator/current/mule-rest-validator.xsd" ``` ## Configure the REST Validator Extension To configure the REST validator extension, add the following syntax in your Mule artifact: `` This snippet contains the required attributes for configuration. You can specify [additional attributes](#config-reference) to customize the extension. The following example illustrates how to use attributes deserializing strategies: ```XML ``` ## Use the REST Validator Operation After you configure the REST validator, you can start using the validator operation: **Operation Name** `validate-request` **Description** Validates a request against the specified RAML or OAS specification in the configuration. **Usage Example** `` **Attributes Description** The following table lists the attributes and provides their descriptions:
AttributeDescriptionRequired?

attributes

A DataWeave expression that extracts the attributes to validate. Default value: #[attributes]

No

payload

A DataWeave expression that extracts the payload to validate. Default value: #[payload]

No

config-ref

A REST validator configuration.

Yes

**Output** If the request does not violate the defined schema, the validation ends successfully and the result of the operation does not modify the HTTP request attributes. Conversely, default values are added to the schema validation and the output includes the original and new HTTP request attributes. **Error Types** The `validate-request` operation might raise different errors if a problem occurs when retrieving a file or if the validation does not end successfully: - `REST-VALIDATOR:BAD_REQUEST` Error raised when some of the attributes do not match with the schema. The attributes that are considered during the validation include: - Form parameters - Headers - Query parameters - URI parameters - `REST-VALIDATOR:METHOD_NOT_ALLOWED` Error raised when the schema does not support a particular method for the required resource. - `REST-VALIDATOR:RESOURCE_NOT_FOUND` Error raised when the root schema or some related file cannot be retrieved. ## REST Validator Extension Configuration Reference The following table describes the attributes that you configure for your validator extension:
AttributeDescriptionRequired?

name

A unique identifier for your configuration.

Yes

api

If you are using a version of the REST validator later than 2.0.0, you must use the raml attribute. This includes the location of the specification file against which the requests are to be validated.

Yes

parser

The parser used to validate the requests:

  • AUTO (default)

    APIkit attempts to initiate the validation using AMF. If errors occur, the RAML parser performs the validation.

  • AMF

    The APIkit router uses AMF to read the API and validate incoming requests.

  • RAML

    The APIkit router uses the RAML parser to read the API and validate incoming requests.

No

keepApiBaseUri

Specifies whether you can override the baseUri property in the specification with the URI of the deployed application. If you must use the console operation, set this property to true. The default value is false.

If you are using a REST validator version that is later than 2.0.0, use the keepRamlBaseUri attribute.

No

queryParamsStrictValidation

Validates whether all the query parameters in the request are defined in the specification file. If some of the parameters are not specified, the validation fails. The default value is false.

No

headersStrictValidation

Validates whether all the required headers defined in the specification are defined in the request. If some of the parameters are not specified, the validation fails. The default value is false.

No

attributesDeserializingStrategies

Allows parsing of the HTTP headers that contain an array of values that are separated by commas.

No

## REST Validator and APIkit Compatibility Reference You can share the REST validator (`pom.xml` dependency) across applications by using a domain. However, if some of those applications also have a dependency on APIkit, that version of APIkit in each application must match the one required by the REST validator version that you use in your domain. Per the following table of compatibilities, for example, if you use the REST validator v2.2.0 in your domain, all your applications using APIkit must import the 1.4.2 version:
Rest Validator VersionAPIkit REST Module Version

2.3.2

1.11.17

2.3.1

1.10.4

2.3.0

1.10.0

2.2.4

1.9.0

2.2.3

1.8.3

2.2.2

1.7.0

2.2.1

1.5.3

2.2.0

1.4.2

2.1.3

1.3.17

2.1.2

1.3.11

2.1.1

1.3.5

2.1.0

1.3.5

2.0.0

1.2.0

1.2.0

1.1.16

1.1.1

1.1.1

--- product: API Manager version: 2.x is-latest-version: true keywords: configure, HTTPS endpoint --- # Configuring an HTTPS Endpoint > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can automatically deploy an API proxy using an HTTP listener (inbound HTTP endpoint) with minimal setup. You can use this approach if you do not foresee any security concerns in your Anypoint Platform API setup. Otherwise, you must configure your API proxy with an HTTPs listener (inbound HTTPS endpoint), instead of an HTTP listener. MuleSoft requires that you provide your own certificate when configuring your HTTPs setup. The certificate you use can be: - A self-signed certificate to be used for demo purposes - A custom TLS certificate with validity within your organization - A trusted Certificate Authority (CA) certificate If your backend uses HTTPS with a self-signed certificate or custom TLS certificate, you must configure the API proxy requester with the corresponding certificate. Depending on your business use case, you can use any of the following recommended ways to configure your API proxy: - [Use a certificate configured through the UI by leveraging Secrets Manager](https://docs.mulesoft.com/api-manager/latest/building-https-proxy): Upload your certificate to a secure vault within API Platform, make it available when you configure the proxy through the secrets manager, and then deploy the secure API proxy to the target runtime, such as CloudHub, Runtime Fabric, or on-premises deployment. - [Use a certificate defined in already deployed Mule domain](https://docs.mulesoft.com/api-manager/latest/proxy-domain-support) Configure the certificate in the domain so that the API proxy HTTPS Listener references it, and then deploy the secure API proxy to the target Runtime Fabric, or on-premises target. (CloudHub is not supported with this approach because it does not support Mule domains.) - Use a certificate configured with Anypoint Studio For this approach, download the API proxy, open it in Anypoint Studio, and [manually configure HTTPS](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service). You can then deploy the proxy to the target runtime, such as CloudHub, Runtime Fabric, or on-premises deployment. (If the target runtime is on CloudHub, use port 8082 when working with HTTPs.) ## See Also - [Build an HTTPS Service](https://docs.mulesoft.com/mule-runtime/latest/build-an-https-service) - [Building an HTTPS API Proxy](https://docs.mulesoft.com/api-manager/latest/building-https-proxy) - [Secrets Manager](https://docs.mulesoft.com/anypoint-security/index-secrets-manager) - [Domain Support for Mule 4 API Proxies](https://docs.mulesoft.com/api-manager/latest/proxy-domain-support) - [Shared Resources](https://docs.mulesoft.com/mule-runtime/latest/shared-resources) --- product: API Manager version: 2.x is-latest-version: true --- # Create an Agent Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Create an agent instance in API Manager to expose your agent and configure its runtime, endpoint, and routing settings. After creating the agent instance, you can verify its identity using GoDaddy ANS to associate it with a domain and enable its verified status in Anypoint Exchange. ## Requirements Before you begin, make sure that: - The API instance is deployed and accessible - You have access to a target runtime (for example, Flex Gateway) - You have the required permissions to manage API instances ## Create an Agent Instance 1. In Anypoint Platform, go to **API Manager**. 2. Click **Add new instance**. 3. Select the agent or API asset you want to deploy. 4. Configure the runtime settings: - Select the target gateway - Choose the deployment configuration 5. Configure the endpoint settings: - **Consumer endpoint**: The public endpoint where the agent is exposed This endpoint is used to derive the domain that identifies the agent during verification. 6. Configure the upstream service: - Provide the target service or backend configuration 7. Review the configuration and click **Deploy**. After deployment, the agent instance is created and available in API Manager. ## Next Steps After creating the agent instance: - Verify the agent identity using GoDaddy ANS - Complete domain validation to enable verified status - Confirm that the agent displays as verified in Anypoint Exchange Before verification, ensure that your environment is properly configured. For more information, see [Prepare Your Environment for Agent Verification](https://docs.mulesoft.com/api-manager/latest/godaddy-set-up) --- product: API Manager version: 2.x is-latest-version: true --- # Create API Groups and Add API Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To package a set of APIs, you first create an API Group and then add the relevant API instances to the group. If you want your API Group to be discovered by consumers, you must publish it to Exchange. Using the following information, you create an API Group, including creating an API Group, creating the very first version of that group, and creating the very first group instance. Additionally, you add API instances to the API Group instance. You can add API instances to the API Group instance based on the environment (production, sandbox, or others) in which you create the API Group instance. For example, if you created an API Group instance in a production environment, you can add API instances to the API Group instance only from production. You create API Groups using the following steps: 1. [Create an API Group](#create-api-groups) The first step to creating an API Group that can be used by consumers is to create an API Group. 2. [Add API instances to the new API Group](#adding-api-instances-to-groups) After you create the API Group, you then add API instances to this group for the first time. ## Task Prerequisites Before you begin, you must have: - At least one API instance in your organization or business group Otherwise, you will not be able to find the required organization or business group in the list. - API Group Administrator permissions to create API Groups ## Create API Groups You create an API Group at the organization level. To create API Groups: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups** > **Create API Group**. 3. In the **API Group name** field, specify a name for the API Group that you want to create: for example, `Social Chatter`. 4. In the **API Group version** field, specify the version for the API Group: for example, `v1`. 5. Optionally, in the **API Group instance label** field, specify a label for the API Group, such as `Internal` if you want to use it for internal purposes. 6. Click **Continue**. The **Creating a new group** page is displayed. You are now ready to [add API instances](#adding-api-instances-to-groups) to the API Group. ## Add API Instances to API Groups Your API Group is not functional until you add the API instances to the group that you want to bundle. When you add API instances to an API Group, you can add: - Only those API instances that belong in the same business group or organizations - Only those API instances that belong to same environment type as the API Group instance - Only those API instances that belong to the same identity provider (IdP) You cannot mix IdPs in an API Group instance. To add a new API instance to a new API Group: 1. On the **Creating a new group** page, select an environment from the **Select environment** drop-down list: 2. From the **Select an API** list, select the API instance that you want to add. 3. From the **Select a version / instance** list, select the version of the API instance that you want to add to the group. 4. If you want to include additional API instances in the API Group, click **Add** and specify the details. 5. If the API instance and the API Group belong in different business groups: 1. Click **Add Organization**. 2. Select the organization or business group in which your API instance is available and click **Add**. 3. Select the environment, API instance, and version that you want to add. 6. Click **Save**. Your API instances are now added to the API Group. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Modify API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-modifying-groups) - [Publish API Groups to Exchange](https://docs.mulesoft.com/api-manager/latest/api-groups-publishing-to-exchange) - [Deprecate API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deprecating-groups) - [Delete API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deleting-groups) --- product: API Manager version: 2.x is-latest-version: true keywords: grant access, api, contracts --- # Creating Client Applications with the Connected App Feature > For the full documentation index, see: https://docs.mulesoft.com/llms.txt For automation use cases, you can use the Connected App feature to create and manage client applications. Connected apps help users delegate their access without sharing sensitive credentials or giving full control of their applications to third parties. Actions taken by connected apps are audited, and users can revoke access at any time. ## Creating a Connected App To create a connected app, see [Anypoint Platform Connected Apps for Developers](https://docs.mulesoft.com/access-management/connected-apps-developers). When you create the connected app to manage client applications, ensure that you: 1. Select **App acts on its own behalf (client credentials)** for **Type**. 2. Add the **Application Creator** scope. 3. Select your root organization for the **Business Group** associated with the **Application Creator** scope. The new connected app can now create client applications and manage the client applications that it creates. ## Client Application Management When a connected app creates a client application, the owner of the connected app is the owner of the new client application. The owner can add additional users as owners by using API Manager. The connected app can manage the client application it created, and can perform the following actions: - Add users as client application owners - Request access to an API instance - Request a tier change - Reset a client applications secret You can’t add a connected app as an owner of a client application. Connected apps can only manage the client applications they create. ## Creating a Client Application with the API Manager API After creating your connected app, you can make requests to the API Manager API to create and manage client applications. This section only demonstrates how to create a client application. For more information about the API Manager API requests to manage client applications, see [API Manager API Documentation](https://dev-portal.mulesoft.com/apis/api-manager.html). To create a client application with the API Manager API: 1. Collect the following information to obtain your Authorization Token: - ``: **Id** of your connected app - ``: **Secret** of your connected app 2. Execute the following request to obtain your Authorization Token after replacing the placeholders with the following: ```ssh curl --location --request POST 'https://anypoint.mulesoft.com/accounts/api/v2/oauth2/token' \ --header 'Content-Type: application/json' \ --data-raw '{ "grant_type": "client_credentials", "client_id": "", "client_secret": "" }' ``` 3. Collect the following information to create your client application: - ``: **Organization ID** for the organization where you want to create the connected app - ``: API instance ID of the API instance you’re creating a client application for - Client Application parameters: - `name`: Name of the application - `description`: Description of the application - `url`: URL of the application - `redirectURI`: An array of redirect Uris - `grantTypes`: An array of Grant Types, for example: `"password"`, `"implicit"`, `"client_credentials"`, `"authorization_code"`, and `"refresh_token"` - `apiEndpoints`: “true” or “false” value indicating whether to automatically register the redirect URIs. 4. Execute the following request to create your client application after replacing the placeholders with the following: ```ssh curl --X POST 'https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations//applications?apiVersionId=' \ --header 'Authorization: bearer ' \ --header 'Content-Type: application/json' \ --data '{ "redirectUri": ["http://example.com/"], "apiEndpoints": false, "name": "Sample Client Apps Name", "description": "Create this App for Sample Client Apps via API 1", "url": "https://www.example.com/app-test1" } ' ``` ## See Also - [Request Access to API Instances from Exchange](https://docs.mulesoft.com/exchange/to-request-access) - [Remove API Instance Contracts](https://docs.mulesoft.com/api-manager/latest/remove-client-app-latest-task) - [Obtain Client ID and Client Secret Credentials of a Client Application](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task) --- product: API Manager version: 2.x is-latest-version: true --- # Delete API Group Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You might want to delete an API Group instance if it is no longer required based on your business needs. If you want to delete the API Group itself, you must first delete all the associated API Group instances, one by one. ## Task Prerequisites Before you begin, ensure that you have the API Group Administrator permissions to be able to delete an API Groups instance. To delete an API Group: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. Select the version of the API Group that you want to delete. 4. Click **…​** > **Delete**. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Create API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-creating-groups) - [Modify API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-modifying-groups) - [Publish API Groups to Exchange](https://docs.mulesoft.com/api-manager/latest/api-groups-publishing-to-exchange) - [Deprecate API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deprecating-groups) --- product: API Manager version: 2.x is-latest-version: true --- # Delete API Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can delete an API instance and its version if you no longer need to manage it from API Manager. Deleting an instance from API Manager does not delete its referenced asset from other locations, such as Anypoint Exchange (Exchange) or file system. You cannot delete an API specification that is currently used in one or more API instances or versions being managed in API Manager. To delete API instances from API Manager: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance you want to delete. 3. Select **Actions** > **Delete API**. 4. Click **Delete** to confirm. Your API instance is now successfully deleted. --- product: API Manager version: 2.x is-latest-version: true --- # Deploy Your API Proxy > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can deploy your API proxy to CloudHub, Runtime Fabric, or a hybrid cloud environment. The resources allocated to the proxy application varies based on the type of proxy you are using. For example, the CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. If required, modify the resource allocation from [Runtime Manager](https://docs.mulesoft.com/cloudhub/deploying-to-cloudhub#change-settings-of-a-deployed-application.adoc). ## Prerequisites Before you deploy your API proxy, complete the following requirements if you work in a Runtime Fabric or hybrid cloud environment: - Runtime Fabric - Obtain the Manage APIs Configuration and Deploy API Proxies permissions on your account. - Use Mule version 4.1.2 or later. - Hybrid: - For private servers, obtain access to a Mule runtime engine (Mule) instance configured for your organization. For information about how to configure a Mule instance as a server, see [register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create). - Register your private server with a Mule agent that is compatible with your Mule instance. Use the Mule Agent specified in the release notes. ## Deploy Your API Proxy Deploy your proxy by completing the following steps: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Add new API**. 3. Select **Mule Gateway** as your runtime. 4. Select **Deploy a proxy application** for **Proxy type**. 5. If you selected to deploy a proxy application, select the **Target type** from the following options: - **CloudHub 2.0**: Select this option if you want to use the Mule runtime hosted by MuleSoft in a container-based cloud infrastructure. The CloudHub 2.0 proxy includes a CPU with 0.1 vCores by default. 1. Select a space. To learn more about spaces, see [Shared Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-shared-space-about) and [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ch2-private-space-about). 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. - **CloudHub**: Select this option if you want to use the Mule runtime hosted on the cloud by MuleSoft. The CloudHub proxy includes a CPU with 0.1 vCores and a memory of 500 MB, by default. 1. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 2. Enter a **Proxy app name**. - **Hybrid:** Select this option if you want to use a Mule runtime instance running on an on-premises server that is registered in Runtime Manager. See [Register a server in Runtime Manager](https://docs.mulesoft.com/runtime-manager/servers-create) for more information. 1. Select a target from the list or click **Add server**. 2. Enter a **Proxy app name**. - **Self-managed Server:** Select this option if you want to create a JAR file to deploy an API proxy to a Mule runtime instance running on an on-premises server that is not registered in Runtime Manager. For more information, see [On-Premises Mule Runtime Deployment Model](https://docs.mulesoft.com/on-premises/latest/mule-deployment-model). Deploying an API proxy to a self-managed server in API Manager doesn’t deploy the proxy to your on-premises server. After you deploy the proxy in API Manager, deploy the proxy to your on-premises server: . [Download your new API proxy JAR file](https://docs.mulesoft.com/api-manager/latest/download-proxy-task). . [Deploy the JAR file to your on-premises server](https://docs.mulesoft.com/mule-runtime/latest/deploy-on-premises). - **Runtime Fabric:** Select Runtime Fabric if you want to deploy API Proxies to a Mule runtime engine that is managed on Runtime Fabric. See [Deploying API Proxies to Runtime Fabric](https://docs.mulesoft.com/runtime-fabric/latest/proxy-deploy-runtime-fabric) for more information. 1. Select a target from the list. 2. In **Runtime version**: 1. Select the **Runtime Channel**. 2. Select the **Version** for Mule runtime. 3. Select the **Java version**. 3. Enter a **Proxy app name**. 1. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select the **Asset type** from the following options: - **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset. Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML. - **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset. For WebSocket APIs, select HTTP and then choose the WebSocket subtype when selecting the API from Exchange. WebSocket instances can use HTTP or AsyncAPI assets from Exchange. - **SOAP API:** Select this option if you have a WSDL API definition file or an external link to the file. Upload a WSDL file for your SOAP API or add the link to the file. - **GraphQL API:** Select this option if you have a GraphQL schema definition file you want to include for your asset. Upload the GraphQL schema definition for your GraphQL API. 3. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 4. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). 1. Click **Next**. 2. Configure the downstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

3. Click **Next**. 4. Configure the upstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

5. Click **Next**. 6. Review your selections and edit them if necessary. 7. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. ## See Also - [Configuring an HTTPS Endpoint](https://docs.mulesoft.com/api-manager/latest/https-reference) --- product: API Manager version: 2.x is-latest-version: true --- # Deployment Error When Configuring API Autodiscovery > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When you configure Mule Gateway for API autodiscovery, you might receive the following "failed to deploy artifact" error: ```text org.mule.runtime.deployment.model.api.DeploymentException: Failed to deploy artifact [accounts] Caused by: org.mule.runtime.api.exception.MuleRuntimeException: org.mule.runtime.deployment.model.api.DeploymentInitException: PropertyNotFoundException: Couldn't find configuration property value for key ${apiId} from properties provider Domain properties - within resolver Deployment properties trying to process key apiId - within resolver global-properties configuration attributes trying to process key apiId - within resolver environment properties provider trying to process key apiId - within resolver Deployment properties trying to process key apiId - within resolver External files trying to process key apiId - within resolver Deployment properties trying to process key apiId ``` ## Cause This issue occurs if you did not add the `apiId` property in the `config.properties` file, and failed to modify the value for the `apiId` attribute in the `api-gateway:autodiscovery` element. The Autodiscovery process runs on a specific instance of API Manager. For that reason, you must specify a valid `apiId` of type `long`. If you deployed a proxy application through API Manager or downloaded the auto-generated proxy, this setting is automatically configured. ## Solution To resolve this issue: 1. Navigate to the config.properties file and append the following property and value pair: ```text apiId=[your-specific-value] ``` 2. In your element, set the `apiID` attribute to the `apiId` property in the config.properties file: ```text apiId=${apiId} ``` ## See Also - [Configure Property Placeholders](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-to-configure) - [Known Issues](https://help.salesforce.com/s/issues) --- product: API Manager version: 2.x is-latest-version: true --- # Deprecate API Group Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You might want to deprecate an API Group instance if a more recent version of the group instance exists. Deprecating an API Group instance from API Manager does not deprecate the API Group asset in Exchange. After an API Group instance is deprecated, no new contracts are accepted. To deprecate an asset in Exchange, see [To deprecate asset](https://docs.mulesoft.com/exchange/manage-versions). ## Task Prerequisites Before you begin, ensure that you have the API Group Administrator permissions to be able to deprecate an API Groups instance. To deprecate an API Group: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. Select the version of the API Group that you want to deprecate. 4. Click **…​** > **Deprecate**. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Create Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-creating-groups) - [Modify Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-modifying-groups) - [Publish API Groups to Exchange](https://docs.mulesoft.com/api-manager/latest/api-groups-publishing-to-exchange) - [Delete API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deleting-groups) --- product: API Manager version: 2.x is-latest-version: true --- # Deprecating an API instance on API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt While transitioning consumers of your API to an updated instance, you can prevent developers from signing up for access to your old API instance. As an API administrator, you mark an API as deprecated to remove the invitation for developers to request access from the portal page. Existing application contracts remain active but no new contracts can be created for that API instance. Deprecated APIs have an indicator in any location where they appear showing they are deprecated. A badge in search results indicates that the instance is deprecated. 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance you want to deprecate. 3. Select **Actions** > **Deprecate API**. 4. Click **Ok**. The API is now deprecated. ## See Also - [About Sharing Assets, including an API](https://docs.mulesoft.com/exchange/to-create-an-asset) - [To Request Access to an API](https://docs.mulesoft.com/exchange/to-request-access) --- product: API Manager version: 2.x is-latest-version: true --- # Determining API Instance ID on API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager generates the `apiId` of new API instances managed by API Manager and displays the ID on the API instance dashboard. The API Instace ID cannot be changed. To find the API instance ID: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance whose ID you want. The API instance ID is displayed under **API Instance ID**. --- product: API Manager version: 2.x is-latest-version: true --- # Domain Support for Mule 4 API Proxies > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule runtime engine (Mule) enables you to share common resources among Mule applications by defining these resources within a Mule domain. Other Mule applications can then inherit this domain. Your Mule applications, when accordingly configured, can access the [resources](https://docs.mulesoft.com/mule-runtime/latest/shared-resources) declared in your domain. Because every autogenerated proxy is a preconfigured Mule application, you can define multiple API proxies under the same domain. You create a domain when you auto-deploy multiple proxies that use the same host and port but have a different path. ## API Proxies and Domains Overview API Manager enables you to automatically configure an API proxy to inherit an existing domain. All API proxies use one of the following listener configurations when referencing a domain: - For inbound HTTP endpoints: `api-proxy-listener-http` - For inbound HTTPs endpoints: `api-proxy-listener-https` Note that domains used by APIs are not supported by Runtime Fabric or CloudHub support domains. **Important:** You may define several dependencies in a domain. Ensure that the versions of the dependencies defined in the domain have the same or later version than the ones defined in the API proxy that references the domain. All the dependencies defined in the domain override the dependencies defined in the API proxy (older or newer). For example, if the API proxy depends on a functionality defined in the HTTP transport, but is referencing a domain using an older version of that transport, errors are thrown at runtime. ### Usage API proxy listeners must inherit your domain HTTP listener configuration by using the listener configuration defined in the target domain. The following code illustrates the HTTP listener configuration defined in a target domain: ```xml ``` For HTTP listener configuration defined in the domain, the listener setup on the API proxy must be defined as: ```xml ... ``` ## Configure the Domain Used by an API Proxy Configure the domain used by an API proxy by completing the following steps: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Add new API**. 3. Select **Mule Gateway** as your runtime. 4. Select **Deploy a proxy application** for **Proxy type**. 5. Select **Hybrid** for **Target Type**, then select the target server. 6. Click **Next**. 7. Select an API from the following options: - Click **Select API from Exchange** if you have an API shared with you through Exchange that you want to manage. 1. Click the API from the list under **Select API**. You can search for a specific API if needed. 2. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 3. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). - Click **Create new API**: 1. Enter a **Name** for the new API asset. 2. Select the **Asset type** from the following options: - **REST API:** Select this option if you have a RAML or OAS API definition file you want to include for your asset. Upload either a RAML or OAS file for your REST API. Versions 2.0.0 and later are the recommended versions for OAS or RAML specs, because these versions add native OAS support. If you upload an OAS API specification to an API proxy version 1.0 or earlier, your API specification is translated to RAML. - **HTTP API:** Select this option if you do not have an API definition file you want to include for your asset. For WebSocket APIs, select HTTP and then choose the WebSocket subtype when selecting the API from Exchange. WebSocket instances can use HTTP or AsyncAPI assets from Exchange. - **SOAP API:** Select this option if you have a WSDL API definition file or an external link to the file. Upload a WSDL file for your SOAP API or add the link to the file. - **GraphQL API:** Select this option if you have a GraphQL schema definition file you want to include for your asset. Upload the GraphQL schema definition for your GraphQL API. 3. Update the **Asset type**, **API version**, and **Asset version** if you are not using the latest version. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). 4. If you chose a **RAML/OAS** asset type, view the **Conformance Status** of the API to ensure the API is conformant. If the **Conformance Status** is nonconformant, after deployment, view the **Governance Report** to find and fix the conformance issues. For more information about the **Governance Report**, see [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances). 8. Click **Next**. 9. Configure the downstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Protocol

Specifies whether to use HTTP or HTTPS for the validations.

Yes

If you select HTTPS, specify a TLS context for inbound traffic.

Inbound TLS

Specifies the TLS context to secure inbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

Port

Specifies the number to use if the displayed port is incorrect.

Yes

Base path

Specifies the URL prefix for all API paths, relative to the host root. It must start and end with a leading slash /. If the final slash isn’t provided, the system adds it automatically.

Yes

Instance label

Specifies a label for the API.

No

If you have multiple managed instances of the same API, add a label to differentiate each instance from the others.

Advanced Options

Consumer endpoint

Specifies a proxy application’s address for consumers to use for sending requests.

No

Client provider

Specifies a client provider for the API.

Yes

Anypoint Platform acts as the client provider by default. To configure an external client provider, see Client Providers.

Request timeout

Specifies the duration after which a request times out.

No

Proxy Version

Specifies the version of the proxy to use for the endpoint.

No

Service Name

Name of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Service Port

Port for your WSDL your service.

Yes

Only avaliable for WSDL APIs.

Service Namespace

Namespace of your WSDL service.

Yes

Only avaliable for WSDL APIs.

Enable Console

Specifies whether you can expose and test your API specification.

No

You can specify a different path in Console Path, for example, /spec/*. Only available if you have an attached API definition.

Validations

Specifies whether to validate inbound requests against a provided specification.

No

Only available if you have an attached API definition.

Strict validations (optional)

Specifies whether to validate inbound requests against query parameters.

No

Only available if you have an attached API definition.

User Domain

Specifies whether to use an API gateway domain.

No

If you chose Hybrid as the proxy deployment target previously in the configuration, ensure that you select this option.

10. Click **Next**. 11. Configure the upstream configuration settings: Expand for configuration settings.
Field NameDescriptionRequiredNotes

Upstream URL

The URL to access for the proxy or the API.

Yes

For example, you can use the URL of your API asset in Exchange.

Outbound TLS

Specifies the TLS context to secure outbound traffic.

No

If you can’t see a context, ensure that you have the correct permissions.

12. Click **Next**. 13. Review your selections and edit them if necessary. 14. If you are ready to deploy, click **Save & Deploy**. Otherwise, you can select **Save**, to save the instance and deploy it at a later time. 15. After saving the API proxy configuration, perform one of the following steps: - Deploy the API proxy to the selected target (**Settings**, under **Deployment Configuration**). - Download the API proxy (**Actions**) and edit it in Anypoint Studio to customize your target domain before deploying it. ## Configuring a Domain for the First Time When referencing a domain, Mule reads the domain Maven coordinates from the API proxy `pom.xml` file and looks for an already deployed domain with the same semantic name. For example, in the case of an API gateway domain with the version specified in the previous example, the semantic name is: `gateway-proxy-domain-1.0.0-mule-domain`. For a proxy to leverage the domain, ensure that the domain template is specified in the API proxy `pom.xml` as a provided dependency. To configure a domain for the first time: 1. Obtain a domain artifact in one of the following ways: 1. Download the [API Gateway domain template](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/). 2. Develop your own custom domain, using the naming convention predefined in the autogenerated proxy: - `api-proxy-listener-http`: The listener configuration for HTTP communications - `api-proxy-listener-https`: The listener configuration for HTTPS communications 2. Copy the Maven artifact to the `domains` folder of your running Mule distribution, for example, `gateway-proxy-domain-1.0.0-mule-application-template.jar`. 3. Replace `mule-application-template` with `mule-domain`, resulting in the string: `gateway-proxy-domain-1.0.0-mule-domain.jar`. **Tip:** Ensure that the name of the artifact and its Maven coordinates match, for example: ```xml com.mulesoft.anypoint gateway-proxy-domain 1.0.0 mule-domain ``` > [!WARNING] For Mule 4.2.2 or later to link to generated proxies, the domain file must be named > `proxy-shared-domain.jar` when copied to the `domains` folder. 4. Customize the domain template to fit your usage scenario: com.mulesoft.anypoint gateway-proxy-domain 1.0.0 mule-domain provided ## Avoiding Port Conflicts To successfully register an API, you must deploy the API proxy to a Mule instance using a unique endpoint URL. Automatically generated proxies use the path: `http://0.0.0.0:8081`. To avoid a conflict when running multiple proxies using the same domain, ensure that the proxy paths are unique. Additionally, if you have multiple domains deployed on the same Mule instance, each listener configuration must have a unique port for all domains to be successfully deployed and available to the deployed proxies. ## API Gateway Domain Template If you choose to download and manually configure your API proxy, use the **API Gateway domain template**. The [API gateway domain template](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/) is configured to have a shared HTTP listener configuration ("api-proxy-listener-http") listening on the 8081 port. You can also have a shared HTTPS listener configuration ("api-proxy-listener-https"). To use either configuration, uncomment code from your API gateway domain template and configure your TLS context, such as certificates and passwords. The following list provides the available listeners configurations: - `api-proxy-listener-http`: Used for HTTP communications, binds to all interfaces and uses port 8081 by default. - `api-proxy-listener-https`: Used for HTTPS communications, binds to all interfaces.+ This domain includes a predefined `config.properties` file, which enables you to define settings dynamically without having to recompile the domain. The following example illustrates the properties in the `config.properties` file: ```Properties proxy.port=8081 implementation.protocol=HTTP inbound.keystore.path=path inbound.keystore.keyPassword=changeit inbound.keystore.password=changeit inbound.keystore.algorithm= inbound.keystore.type=JKS inbound.keystore.alias=alias ``` > [!WARNING] If you are using Mule 4.2.2 or later with the API gateway domain template 1.0.x, you > must modify the domain Java archive (JAR) file for Mule to link with the generated proxies: > > - In `META-INF/maven/com.anypoint.mulesoft/gateway-proxy-domain/pom.xml`, change the value of > `groupId` to `com.mulesoft.anypoint`. > > - In `META-INF/mule-artifact/classloader-model.json`: change the value under `"groupId":` for > `com.mulesoft.anypoint`. > > - In `META-INF/mule-artifact/classloader-model.json`, change the value of `groupId` to > `com.mulesoft.anypoint`. ## See Also - [Download Proxies](https://docs.mulesoft.com/api-manager/latest/download-proxy-task) - [API Gateway Domain Template](https://anypoint.mulesoft.com/exchange/org.mule.examples/gateway-proxy-domain/) - [Runtime Domains](https://docs.mulesoft.com/mule-runtime/4.2/shared-resources#assoc_apps_domain) --- product: API Manager version: 2.x is-latest-version: true --- # Downloading an API Proxy > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You use a proxy to manage your API without having to change its implementation and to prevent attacks on the server. Mule Runtime is the server that hosts a Mule proxy application. > [!NOTE] You must have View APIs Configuration permission to download a proxy. You can download a proxy that you generated in API Manager by following this procedure. 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the API instance whose proxy you want to download. 3. Click **Actions** and select **Download Proxy**. ## See Also - [Granting Permission to Access an environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) - [Creating an API instance on API Manager](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) - [Reviewing API Gateway API Autodiscovery concepts](https://docs.mulesoft.com/mule-gateway/mule-gateway-autodiscovery-overview) --- product: API Manager version: 2.x is-latest-version: true --- # Editing an API Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you create an API instance in API Manager, you can edit the instance’s configuration settings. For more information about the API endpoint configuration settings, see: - [Adding an Omni Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-flex) - [Adding a Mule Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) To edit an API instance’s endpoint: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance whose endpoint you want to edit. 3. Click **Settings**. 4. Edit the desired configuration settings fields. 5. Click **Save**. --- product: API Manager version: 2.x is-latest-version: true --- # Editing, Enabling, or Disabling API Alerts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When creating an alert, you can select if the alert will be enabled or disabled. You can also edit an existing alert and enable or disable the alert. 1. Navigate to **Anypoint Platform** > **API Manager**.. 2. In **API Administration**, click the API instance whose alert you want to edit. 3. Click **Alerts**. 4. Click the **Edit** button on the alert you want to edit. ![The API instance alerts list showing an example alert.](/mulesoft/current/en-us/api-manager/latest/_images/edit-enable-disable-alerts-task-7e2ac.png) ## See Also - [Reviewing Alerts concepts](https://docs.mulesoft.com/api-manager/latest/using-api-alerts) - [Testing an API Alert](https://docs.mulesoft.com/api-manager/latest/test-alert-task) --- product: API Manager version: 2.x is-latest-version: true --- # Exporting an API Instance on API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After creating an API instance, you can export it. This exports the API instance endpoint configuration and Exchange asset relationship. You can then import it into another environment in the same business group to create a new API instance. The export file is created as follows: - File format: ZIP - File name format: `{API name}-{version}-{API instance ID}` - File size: 100 MB or smaller > [!NOTE] The following information is not exported with the API instance: > > - The client provider configuration, which is extracted from the target environment when the API > instance is imported. > > - Information stored in the asset such as contracts, policies, and API specifications. To share > this, you can promote the API instance in an API group. To export an API instance: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API you want to export. 3. Click **Actions** and select **Export API**. Your API instance is now successfully exported. ## See Also - [Add an API Instance](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) - [Promote API Instances in API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-promote-api-instance) --- product: API Manager version: 2.x is-latest-version: true --- # Forward Mule API Analytics Events to External Systems > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule API Analytics event forwarding sends API traffic telemetry to third-party analytics, security, or operations tools when built-in views are not enough. You can pull events on a schedule with the Analytics Event API within its retention and throttling rules, configure gateways to POST GZIP-compressed batches to an HTTPS endpoint you operate, or export through Runtime Manager integrations. If gateways post only to your endpoint and skip Anypoint Platform ingestion, Mule API Analytics and API Manager no longer show those calls, so decide visibility requirements before you rely on that path. ## Paths to export Mule API Analytics events - Use the [Analytics Event API](https://docs.mulesoft.com/api-manager/latest/analytics-event-api) to pull data on demand. The API enforces limits on how often and how many events you can retrieve, and events can arrive up to ten minutes after they occur. - Forward Mule API Analytics events from the gateway to a configured HTTP endpoint. On CloudHub, set the `anypoint.platform.analytics_base_uri` gateway property from the **Settings** tab of Runtime Manager. This property sets the base URL where events are posted. ![Event forwarding configuration in Runtime Manager](/mulesoft/current/en-us/api-manager/latest/_images/analytics-event-forwarding.png) In the example above, events are published to `http:///v2/analytics/events` using the POST method and GZIP for compression. This approach can skip publishing events to Anypoint Platform, so Mule API Analytics and API Manager do not display information about those API calls. - Use Runtime Manager to [Export Data to External Analytics Tools](https://docs.mulesoft.com/runtime-manager/sending-data-from-arm-to-external-analytics-software). ## See Also - [Generate Mule API Analytics Reports with the Event API](https://docs.mulesoft.com/api-manager/latest/analytics-event-api) --- product: API Manager version: 2.x is-latest-version: true --- # Gateway Policies in API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt From API Manager, you can apply policies to APIs in Omni Gateway Connected Mode or Mule Gateway. Policies enable you to enforce regulations to help manage security, control traffic, and improve adaptability of your APIs. For example, a policy can control authentication, access, allotted consumption, and service level access (SLA). You can implement these regulations with no modification to the code implementation. Policies are available based on the API type and the gateway where the API instance is deployed. To find the policies available for your gateway, see [Policy Availability by Gateway](https://docs.mulesoft.com/gateway-home/#policy-availability-by-gateway). For more information about specific policies and how to apply them, see: - [Securing Omni Gateway Instances with Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) - [Mule Gateway Policies Overview](https://docs.mulesoft.com/mule-gateway/policies-policy-overview) ## Use Stored Secrets for Sensitive Policy Fields When you apply a policy to an Omni Gateway API instance, sensitive fields (such as passwords and keys) offer two options: - **Enter value**: Type the value directly in the field. - **Use a stored secret**: Reference a blob secret stored in Anypoint Security Secrets Manager (CSM). To use a stored secret, the secret must: - Be of type **Blob**. - Belong to a **Downloadable Secret Group**. Select the secret group from the first dropdown, then select the specific secret from the second dropdown. > [!NOTE] If you update the secret value in an external vault, the runtime picks up the change > automatically. If you update the secret value directly in Secrets Manager (not in an external > vault), you must redeploy the API instance manually for the change to take effect. For information about creating secret groups and blob secrets, see [Create a Secret Group](https://docs.mulesoft.com/anypoint-security/asm-secret-group-creation-task). --- product: API Manager version: 2.x is-latest-version: true keywords: analytics, api, reports --- # Generate Mule API Analytics Reports with the Event API > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager exposes the Mule API Analytics Event API so you can generate CSV or JSON event reports from Manage Reports for selected APIs, versions, environments, and time windows. The service retains about one month of data, can lag up to ten minutes, and throttles callers to ten requests per minute with a twenty-thousand-event cap per request. It suits ad hoc analysis instead of bulk export or continuous synchronization. For reliable delivery of event data into another system, see [Forward Mule API Analytics Events to External Systems](https://docs.mulesoft.com/api-manager/latest/analytics-event-forward) instead of repeatedly polling this API. ## Analytics Event API Limits and Best Practices The Analytics Events API provides a one-month retention policy and a data availability delay of up to 10 minutes. It also enforces a usage limit of 10 requests per minute, with a maximum of 20,000 events per request. Request rates higher than 10 requests per minute are throttled. The API is designed to create ad-hoc reports. It is not intended as a data export tool. Before you start using the API to create reports, review each requirement and restriction: - Do not allow calls to overlap time intervals. - Do not repeat the same request for every API that you have. - Although the Analytics Events API enforces a limit of 10 requests per minute, the best practice is 1 request per minute. - Do not use the Analytics Events API for data synchronization. If you need to synchronize data for events with an external system, see [Forward Mule API Analytics Events to External Systems](https://docs.mulesoft.com/api-manager/latest/analytics-event-forward). ## Create a Report You can create a report to find API events, such as policy violations due to rate limiting or IP blacklisting. If the analytics services or Anypoint Platform are temporarily unavailable, Anypoint Platform may submit multiple data points to avoid any telemetry data loss. This might cause the report that you generate to contain duplicate entries. To create a report: 1. Navigate to **API Manager** > **Mule Analytics** > **Manage Reports** and click **New**. 2. In **Create Report**, select a data source, range, and format. 3. In **Fields**, select **Violated Policy Name**. 4. Save the report. A URL for viewing the report is displayed. 5. Click the URL to view the generated report. ## Run a Report in the Browser The Analytics Event API displays a starting time from which requested data is available. If no data is available, a warning message appears. To run a report in a browser, navigate to the **Manage Reports** page and click **Run** for your desired report: ![anev\_running\_report2](/mulesoft/current/en-us/api-manager/latest/_images/anev-running-report2.png) After the report runs, a CSV or JSON file is generated, containing the analytics data you requested. ### View Report Output with Curl You get the value of `$TOKEN` by running the curl command in this procedure. The command gets the `access_token` JSON property of this response. The authorization header has the form `Authorization: Bearer {$TOKEN.access_token}`. The use of the `jq` command-line JSON processor is one possible solution for obtaining the access token value. Download and install this application or one with the same functionality for this procedure. To view report information programmatically: 1. Open a new terminal window and run this command: TOKEN=$(curl -s https://anypoint.mulesoft.com/accounts/login -d "username=&password=" | jq -r .access\_token) This command sends a request to the authentication servers of the Anypoint Platform and, if the request is successful, returns an access token that’s stored in the `$TOKEN` variable. The value of this variable is displayed below: ```json { "access_token": "54545454-5454-5454-5454-545454545454", "token_type": "Bearer", "redirectUrl": "/accounts/#/cs/profile/home" } ``` 2. Append the access token to the `Authorization` header in the request of the Analytics Reporting API endpoint for your report: 1. Copy the endpoint from the **Manage Reports** page in the Mule API Analytics dashboard. 2. Include the `$TOKEN` variable from the previous step in the next request, as shown in this example that retrieves analytics for organizations without environments: ```console curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com/analytics/1.0//events?format=csv&startDate=2016-01-01&endDate=2016-12-31&fields=Application%20Name.Client%20IP.Resource%20Path" > output.csv ``` 3. If the request is successful, an `output.csv` file is generated in the directory from which you initiated the `curl` request. This next example queries the Analytics Events API for organizations with environments: ```console curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com:443/analytics/1.0//environments//events?format=csv&apiIds=&duration=30d" > output.csv ``` In this example, analytics data is retrieved for the past 30 days from the API with the API ID . The results are generated in a CSV format. This example combines two `curl` commands and displays values in the command prompt window: ```text TOKEN=$(curl -s https://anypoint.mulesoft.com/accounts/login -d "username=myusername&password=mypassword" | jq -r .access_token) curl -H "Authorization: Bearer $TOKEN" "https://anypoint.mulesoft.com/analytics/1.0/42424242-4242-4242-4242-424242424242/events?format=csv&startDate=2016-01-01&endDate=2016-11-10&fields=Application%20Name.Client%20IP.Resource%20Path" echo;echo ``` The command produces output such as: ```text "Application Name","Client IP","Resource Path",Timestamp,"API ID","API Version ID","API Name","API Version Name" "Las Vegas T-Shirt serviceLas Vegas T-Shirt serviceLas Vegas",83.178.96.0,/,2016-10-03T04:27:02.072Z,61460,63811,"test api contracts",1 "Las Vegas T-Shirt serviceLas Vegas T-Shirt serviceLas Vegas",83.178.96.0,/,2016-10-03T05:03:38.774Z,61460,63811,"test api contracts",1 ... ``` ### Request Events for a Specific Environment For organizations that have enabled environments, API events queried using the approach described in the topic belongs exclusively to the "Unclassified" environment. To request events for APIs in a specific environment: 1. Select the environment in the Environment selector and create the report that you want to run. Reports are stored based on the environment. Therefore, different reports exist in different environments. 2. Copy from the UI the report URL generated from creating the report. Note that in addition to the organization ID, the URL also includes `/environment/{Environment ID}`. Anypoint Platform assigns a unique ID to an organization and an environment when they are created. For example, an API ID in the QA environment differs from its ID in the Production environment. 3. To access events for a specific environment, append the environment ID to the report URL. ### Curl Command Options Reference You can add optional query parameters to curl commands, including:
OptionDescription

apiIds

Comma-delimited list of API IDs to include in a query. Omit or specify all or * to include all APIs.

Type: string
Required: no
Example: appIds=42,54

apiVersionIds

Comma-delimited list of API version IDs to include in query. Omit or specify all or * to include all API versions. Ignored if no value was specified for API IDs.

Type: string
Required: no
Example: apiVersionIds=42,54

duration

The duration over which the report should return data. Consists of an integer number denoting quantity and a single-letter suffix denoting units.

Suffix is one of:

  • d: Days

  • h: Hours

  • m: Minutes

  • s: Seconds

To cover a duration of one week, specify 7d as the duration. To cover half a minute, specify 30s.

Type: string
Required: no
Example: duration=45m

fields

Fields to include in the report. Required for CSV output and optional for JSON output. The list of fields can be comma- or period-delimited. Use %20 for spaces. You can use any value in Report data fields reference. Timestamp, API Name, API ID, API Version, API Version ID are always included.

Type: string
Required: no
Example: fields=Hardware%20Platform.Client%20IP.Resource%20Path

format

Determines the serialization format of the returned data. Either csv or json.

Type: string
Required: yes
Example: format=csv

maxResults

Maximum number of events to return. Default value is 20000.

Type: integer
Required: no
Example: maxResults=3

startDate

Starting date and time, as described by http://joda-time.sourceforge.net/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateTimeParser()[ISO Date Time Parser].

Type: date
Required: no
Example: startDate=2016-01-01T08:15:30-05:00

endDate

Ending date and time, as described by http://joda-time.sourceforge.net/apidocs/org/joda/time/format/ISODateTimeFormat.html#dateTimeParser().

Type: date
Required: no
Example: endDate=2016-11-10

## Report data fields reference Your report can query data for one or more of the available data fields:
Data Field NameDescription

Application

Client ID associated with the incoming API request.

Application Name

Name of the application making the API request (only available when a client ID is passed with the request).

Browser

Browser type associated with the incoming API request.

City

The city from which the API request originated (inferred by the IP address of the client).

Client IP

IP address of the client making the API request.

Continent

The continent from which the API request originated (inferred by the IP address of the client).

Country

The country from which the API request originated (inferred by the IP address of the client).

Hardware Platform

The hardware type of the client making the request (such as Mobile, Tablet, Desktop, etc.).

Message ID

Message ID value.

OS Family

The client OS type: Mac OS X, iOS, Windows, Linux.

OS Major Version

Operating system major version.

OS Minor Version

Operating system minor version.

OS Version

Operating system version.

Postal Code

The postal code from which the API request originated (inferred by the IP address of the client).

Request Outcome

Indicates whether a request was successful or resulted in a policy violation.

Request Size

The size (in bytes) of the incoming client request.

Resource Path

The path of the client request.

Response Size

The size in bytes of the API response. See note below.

Response Time

The processing time of the API request.

Status Code

The HTTP status code of the response.

Timezone

The time zone from which the API request originated (inferred by the IP address of the client).

User Agent Name

The complete user agent string for the incoming client request.

User Agent Version

The version of the user agent string for the incoming client request.

Verb

The REST verb associated with the API client request (GET, POST, PATCH, etc.).

Violated Policy Name

The name of the policy violated by the API request (if any).

In your query, if the `Content-Length` header is: - Present: `Response Size` is set to that value. - Not present and the payload is a String: Mule API Analytics calculates the length of the String and reports that value. - Not present and the payload is not a String: Mule API Analytics reports the response size as -1. For example, if the output returned is a DataWeave stream and the `Content-Length` header is not present, the Analytics Event API does not report a response size because the value is not a String. However if your application performs a String conversion, the response size is listed. ## Restrict Client IP Data in Analytics If you don’t want to forward client IP data, set `anypoint.platform.analytics_include_client_ip=false` in the `wrapper.conf` file of your Mule runtime. To set properties, refer to [Configuring Properties](https://docs.mulesoft.com/mule-runtime/latest/configuring-properties). If you choose not to forward client IP data, geolocalized data such as **City**, **Continent**, **Postal Code**, **Country**, and **Timezone** is also not available. ## See Also - [Viewing Mule API Analytics](https://docs.mulesoft.com/api-manager/latest/viewing-api-analytics) - [jq command-line JSON processor](https://stedolan.github.io/jq/) --- product: API Manager version: 2.x is-latest-version: true --- # Getting Started with Managing an Instance > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can use API Manager to apply policies and to add contracts, alerts, and SLA tiers to your API instance. Additionally, you can configure a runtime for your API that runs in CloudHub or CloudHub 2.0. Although you can also deploy your API runtime using Mule runtime engine (Mule) and Hybrid, deploying your API proxy directly to CloudHub is the fastest and easiest. > [!NOTE] If you are running an API with a standalone server, use the > [classic API creation flows](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) to manage your API. You can manage your instance using the following steps: 1. [Create an API asset in Exchange](https://docs.mulesoft.com/exchange/to-create-an-asset#create-an-api-asset) You can create a REST, HTTP (including the WebSocket subtype), AsyncAPI, SOAP, gRPC, or GraphQL API asset in Exchange and manage it as an API instance in API Manager. 2. [Add an API Instance in API Manager](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) An instance represents a proxy or component that serves an upstream. API instances support the application of policies and can be deployed to an API gateway. 3. [Apply a Policy in API Manager](https://docs.mulesoft.com/mule-gateway/policies-included-apply) A policy extends the functionality of an instance and enforces certain capabilities such as security. A policy can control access and traffic. For example, a policy can generally control authentication, access, allotted consumption, and service level access (SLA). ## See Also - [Learn about SLA Tiers](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers) - [Learn about granting access to an API](https://docs.mulesoft.com/api-manager/latest/api-contracts-landing-page) - [More on API proxies](https://docs.mulesoft.com/api-manager/latest/api-proxy-landing-page) --- product: API Manager version: 2.x is-latest-version: true --- # Governing API Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt API Manager is closely integrated with [Anypoint API Governance](https://docs.mulesoft.com/api-governance/). API Governance helps you ensure that every instance of a governed API conforms to standards, such as which policies are applied or whether a TLS context is required. To govern an API instance: 1. [Apply a Governance Ruleset](#apply-a-ruleset) 2. [View and Fix Instance Conformance Issues in API Manager](#view-api-manager) ## Apply a Governance Ruleset To govern API instances, you must apply a governance ruleset to your desired API. To apply a governance ruleset, see [Applying Rulesets to Identified APIs](https://docs.mulesoft.com/api-governance/create-profiles). To create custom rulesets that enforce your own API management standards, see [Creating Custom Governance Rulesets](https://docs.mulesoft.com/api-governance/create-custom-rulesets). ## View and Fix Instance Conformance Issues in API Manager To view the conformance status of an API instance: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click the name of the API instance for which you want to view the conformance status. **Instance Conformance** appears in the **API Summary** pane. 3. If the instance is not conformant, select the **Governance Report** page to view nonconformance details for each ruleset. 4. Click **View details** for each ruleset for more information about the conformance issues. ## See Also - [Instance Conformance](https://docs.mulesoft.com/api-governance/fix-instance-conformance-issues) --- product: API Manager version: 2.x is-latest-version: true --- # Grant Permission to Access an Environment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt To be able to fully access API Manager operations within an environment, users must have the API Manager Environment Administrator permission. An API Manager Environment Administrator role is associated with tasks performed only in API Manager. You can change permissions for API Manager-related operations from Anypoint Access Management. Regarding roles, note that: - Roles and permissions assigned to a user in one particular business group are independent of the roles and permissions assigned to that same user in other business groups. - Roles are business group-specific, so ensure that you are in the correct business group for which to manage roles by clicking the menu next to your user icon. The following diagram illustrates the tasks enabled by having each permission: ![permission relationships](/mulesoft/current/en-us/api-manager/latest/_images/apim-permissions-relationships.png) In this diagram, note that an Environment Administrator has access to all the functionalities and permissions. Outer permissions provide permission to the inner permissions. For example, `Manage Alerts` gives permission to View Alerts and to View API Configuration. API Manager supports the following additional environment-level permissions:
PermissionDescriptionNotes

Deploy API Proxies

Deploy or redeploy an API proxy

Requires Runtime Manager and Hybrid access. This role enables deployment access from API Manager, but cannot guarantee that deployment is successful due to its dependency on Runtime Manager or Hybrid.

Manage Alerts

Create, edit, and delete alerts.

Manage APIs Configuration

Import APIs from Exchange

This permission also enables a user to promote an API to another environment, edit the configuration of an API, and delete APIs.

This permission is per environment. API visibility cannot be restricted to specific users inside your organization.

Manage Contracts

Deploy, reject, and revoke contracts

This permission also gives the user permission over tiers.

Manage Policies

Create, edit, delete, enable, disable, and reorder a policy

View Alerts

List alerts and view configuration summary of an alert

View APIs Configuration

List and view APIs

List APIs, view configuration summary of an API, and download proxies.

This permission is per environment. API visibility cannot be restricted to specific users inside your organization.

View Contracts

List contracts and their configuration

Can also list SLA tiers and their configuration.

View Policies

View a listing of policies and view the configuration of a policy

## Grant Permissions To grant environment permissions to roles from API Manager: 1. **Click Access Management** > **Users** > **_a user to give permissions_** > **API Manager** > Permissions. 2. Select the permissions for the user and click ![blue plus icon](/mulesoft/current/en-us/api-manager/latest/_images/blue-plus.png) to save the permissions: ![How to set permissions in Access Management](/mulesoft/current/en-us/api-manager/latest/_images/apim-user-perms.png) > [!NOTE] The following API Manager 1.x roles are incompatible with API Manager 2.x: > > - API Versions Owner > > - API Creator > > - Portals Viewer ## See Also - [Promote an API instance to another Environment](https://docs.mulesoft.com/api-manager/latest/promote-api-task) --- product: API Manager version: 2.x is-latest-version: true --- # Handling API Proxy Status Codes > For the full documentation index, see: https://docs.mulesoft.com/llms.txt In Mule 4, WSDL, RAML, HTTP, and HTTPS proxies handle errors and requests as described in the following tables. Mule 4 returns different error codes, depending on the proxy type, or no error code in response to problematic requests. This table shows whether or not Mule returns a 504, 400, or 404 error code when your WSDL, RAML, HTTP, and HTTPS proxy receives a problematic request.
Error CodeWSDLRAMLOASHTTPHTTPS

504: request timeout

yes

yes

yes

yes

yes

400: bad request (validation result)

yes

no

yes

no

no

404: resource not found

no

yes

yes

no

no

405: method not allowed in API spec

no

no

yes

no

no

--- product: API Manager version: 2.x is-latest-version: true --- # Import Client Applications from Client Providers > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Import existing client applications from external client providers into API Manager so that they can be managed as client applications and used to request access to API instances. Importing a client application doesn’t create or modify the application in the external client provider. The application must already exist in the client provider before it can be imported into API Manager. ## Overview Organizations often manage OAuth client applications outside Anypoint Platform using external identity providers (IdPs), such as Okta. This feature enables you to import those existing client applications into API Manager, where they appear as client applications and can be used to request access to API instances. After you import a client application, you can: - View and manage it from API Manager. - Assign one or more owners to the application. - Use the application to request access to API instances. ## Prerequisites Before importing client applications, ensure that the following requirements are met: - A client provider of type OpenID Connect (OIDC) is configured in Access Management. - Client import is enabled for the client provider. - You have the required permissions to manage client applications. To enable client import for a client provider: 1. In Anypoint Platform, go to **Access Management**. 2. From the left navigation menu, select **Client Providers**. 3. Select an existing client provider or create a new one. 4. In the **Authentication Method** section, expand **Advanced Options**. 5. Select **Enable client import from IdP**. > [!NOTE] The **Enable client import from IdP** option is available only for client providers that > use the OpenID Connect authentication method. You can import client applications using the Anypoint Platform UI, the public API, or the Anypoint CLI. ## Import Client Applications Using the UI This option is available only to users with the **Organization Owner** or **Manage Client Applications** roles. To import a client application using the UI: 1. In Anypoint Platform, go to **API Manager**. 2. From the left navigation menu, select **Client Applications**. 3. Click **Import Application**. 4. In the dialog box, complete the following fields: - **Client Provider**: Select the client provider that manages the external application. - **Client ID**: Enter the client ID of the existing application from the client provider. - **Description** (optional): Provide a description for the application. - **Application URL** (optional): Provide the application URL. 5. Click **Import**. After the application is imported, it appears in the list of client applications as an imported application. To use the application to request access to API instances, you must assign at least one owner to it. ### Import Client Applications Using the Public API You can import client applications programmatically using the public API. A connected app with the `manage:client_application` scope is required. To import a client application, send a request similar to the following: ```bash curl --location --request POST '[https://anypoint.mulesoft.com/apimanager/api/v1/organizations/:orgId/applications](https://anypoint.mulesoft.com/apimanager/api/v1/organizations/:orgId/applications)' --header 'Authorization: Bearer ' --header 'Content-Type: application/json' --data-raw '{ "clientId": "", "providerId": "", "description": "", "url": "" }' ``` After importing the application, add an owner by sending a request similar to the following: ```bash curl --location --request POST '[https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations/:orgId/applications/:applicationId/owners](https://anypoint.mulesoft.com/apiplatform/repository/v2/organizations/:orgId/applications/:applicationId/owners)' --header 'Authorization: Bearer ' --header 'Content-Type: application/json' --data-raw '{ "entityType": "user", "id": "" }' ``` ## Import Client Applications Using the Anypoint CLI You can also import client applications using the Anypoint CLI. Use the following commands: - `api-mgr:application:import` to import the client application. - `api-mgr:application:add-owner` to assign an owner to the imported application. For more information about these commands and their options, see the Anypoint CLI documentation. ## Managing Imported Client Applications After importing a client application and assigning an owner, you can: - Request access to one or more API instances. - Use the application across environments, according to your organization’s access policies. - Manage application ownership from API Manager. --- product: API Manager version: 2.x is-latest-version: true keywords: api, instance, manager, limits --- # Limits in API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt ## API Manager Entity Limits API Manager limits various entity properties and configurations to ensure optimal performance and stability.
LimitValueNotes

API Policies per API

350

Group Instance

500

SLA Tiers per API Version

250

SLA Tier Description

500

Automated Policies per API

50

Max Policy Configuration size

1024000 bytes

## Control Plane API Rate Limits Anypoint Platform applies rate limits per client IP address to requests sent to the following API Manager control plane endpoints. These limits don’t apply to requests sent to your managed API instances. When requests from a client IP address exceed an endpoint’s rate limit, Anypoint Platform returns a 429 (Too Many Requests) status code.
EndpointRate LimitStatus Code

/login

30 requests per second

429

/api/v1/organizations/{organizationId}/environments/{environmentId}/apis/{apiId}/contracts/{contractId}

600 requests per minute

429

/repository/applications/{applicationId}

120 requests per minute

429

/repository/v2/organizations/{organizationId}/applications/{applicationId}

/consumers/api/v1/organizations/{organizationId}/applications/{applicationId}

/xapi/v1/organizations/{organizationId}/exchange-policy-templates/{groupId}/{assetId}/{version}/implementations

120 requests per minute

429

/consumers/api/v1/organizations/{organizationId}/groups/{groupId}/assets/{assetId}/versions/{version}/implementations

## API Group Limits API Manager limits the number of features allowed for each business group.
LimitValueNotes

API Groups per business group

1200

API Group Versions per business group

1200

API Group Instances per business group

2000

## Upstream Service Limits API Manager limits the number of upstream services you can expose through a single consumer endpoint. For the upstream service limits, see [Omni Gateway Limits and Performance Metrics](https://docs.mulesoft.com/gateway/latest/review-prerequisites#limits). ## API Alert Limits
FeatureGoldPlatinumTitaniumIntegration StarterIntegration Advanced

Logs

Documented in Runtime Manager

Documented in Runtime Manager

You receive additional storage that is 10% of the size of purchased storage for indexes for searchable logs. Occupies space per subscription.

Documented in Runtime Manager

Your logs can occupy as much space as you receive with your pricing package.

Searchable Logs

Not available

Not available

You receive additional storage that is 10% of the size of purchased storage for indexes for searchable logs.

Not available

You receive additional storage that is 10% of the size of purchased storage for indexes for searchable logs.

Application Metrics Retention

30 days

30 days

365 days

30 days

365 days

Enhanced API Metrics Retention

30 days. The limit for data in the Client Applications tab is 1 hour.

30 days. The limit for data in the Client Applications tab is 1 hour.

30 days. Data in the Client Applications tab is limited to 1 hour. Data from api_path_metric and api_client_ip_metric tables in advanced mode of custom dashboards is limited to 1 hour.

30 days. The limit for data in the Client Applications tab is 1 hour.

30 days. Data in the Client Applications tab is limited to 1 hour. Data from api_path_metric and api_client_ip_metric tables in advanced mode of custom dashboards is limited to 1 hour.

Custom Metrics Retention

Not available

Not available

365 days in production environments

Not available

365 days in production environments

Basic Alerts for Servers and Mule apps

50 alerts

50 alerts

50 times the number of production vCores in your organization plus 100

6 alerts per server or app

10 alerts per server or app

Basic alerts for APIs

6 alerts per API instance

6 alerts per API instance

10 alerts per API instance

6 alerts per API instance

10 alerts per API instance

Advanced Alerts

Not available

Not available

20 alerts per parent organization

Not available

10 alerts per app or API instance

Telemetry Exporter Connections

Not available

Not available

10 connections per organization

Not available

10 connections per organization

Log Truncation

Maximum of 8 KB per line

Maximum of 8 KB per line

Maximum of 8 KB per line

Maximum of 8 KB per line

Maximum of 8 KB per line

> [!NOTE] Use a minimum screen resolution of 1024 by 768 pixels. --- product: API Manager version: 2.x is-latest-version: true --- # Manage API Group Instance Contracts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you grant access to API Group instances in Exchange, a contract is automatically created between an application and the API instance. You can then manage that contract from API Manager. ## Applied Contracts With API Groups, an application can have multiple contracts with the same API in these scenarios: - An application requests access to an API and the request is approved. In this case, a direct contract is created between the application and the API. This is known as _API instance contracts_. - An application requests access to an API Group instance that consists of an API instance with which the application already has a direct contract. This is known as _API Group instance contracts_. When an application has multiple contracts with the same API instance, only one contract is active at any given time. This is known as _Applied contracts_. The screen capture displays the contract levels and the contract status for the API instance contracts. ![API Group Instance Contracts](/mulesoft/current/en-us/api-manager/latest/_images/api-groups-instance-contracts.png)
1The contracts for an API instance at the instance-level
2The API Group for which the contracts are displayed
3The applications that currently have a contract with the API instance
4The contract that is currently active
5The contracts for an API instance at the API Group-level
An application can have multiple contracts with the different APIs in an API Group. You can view the API instance contracts at the API Group level. The contracts are sorted by the applications that are in contract with the API Group. The contract that is currently active within an API Group is displayed as `Applied`. When an application has multiple contracts with the same API, the least restrictive tier compared with other contract tiers of the same API is set to `Applied`. Only approved contracts can be set to `Applied`. Because a revoked contract is no longer active, it cannot be set to `Applied`. ## Applied Contracts Example To better understand how a contract is set to `Applied` if there are multiple contracts between an API and an application, consider the following example. Good Weather requests access to the `Facebook` API for an application named `Contacts`. A contract is created between `Contacts` and `Facebook`. The consumer uses the same application `Contacts` to request access to an API Group instance named `Social Chatter` which consists of the `Facebook` API among others. A contract is also created between `Contacts` and `Social Chatter`. In this scenario, the application `Contacts` has two contracts: - One directly with API `Facebook` - One indirectly with API `Facebook` because of the contract with API Group instance `Social Chatter` Because `Contacts` has two contracts, the question is which contract is set to `Applied`. Assume that the: - API contract tier is allowed 100 requests per minute - API Group contract is allowed 10 requests per minute In this scenario, the API contract between `Contacts` and `Facebook` is set to `Applied` because it is the least restrictive tier. The user gets 90 more requests per minute than when using the API Group contract. Note that a contract is applied for an API but not for an API Group instance. For example, if the consumer creates a contract between the API Group instance `Social Chatter` and another application `Interests`: - For `Contacts` and API `Facebook`, the applied contract is the API contract. - For `Interests` and API `Facebook`, the applied contract is the API Group instance contract because it is the only contract between the application and the API. `Interests` does not have a direct contract with the `Facebook` API. To view API Group instance contracts: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. From the API Group instance details page, click the `version:instance` link for the API Group instance. 4. Click **Contracts** and expand the instance for which you want to view the contract information: ![View Contracts for API Group Instance](/mulesoft/current/en-us/api-manager/latest/_images/api-group-instance-contracts.png) The contracts for the API Group instances are displayed. To manage API Group instance contracts: 1. In **API Manager**, click **API Groups**. 2. From the API Group instance details page, click the `version:instance` link for the API Group instance. The API Group instance details page is displayed. 3. Click **Contracts** and expand the instance for which you want to view the contract information: ![Manage Contracts for API Group Instance](/mulesoft/current/en-us/api-manager/latest/_images/api-group-instance-manage-contracts.png) The contracts for the API Group instances are displayed. 4. For the API Group instance for which you want to manage the contract, click **…​** > **Revoke**. --- product: API Manager version: 2.x is-latest-version: true --- # Manage Contracts for Anypoint DataGraph > For the full documentation index, see: https://docs.mulesoft.com/llms.txt As an Anypoint DataGraph administrator, you ensure that only authorized client applications can consume the unified schema by granting access based on specified user credentials and the SLA tier. Client applications request access to the unified schema via Anypoint DataGraph. Approving access creates a contract between the client application and the unified schema for its environment, and registers the client application. Refer to [Client Applications and Contracts](https://docs.mulesoft.com/api-manager/latest/api-contracts-landing-page) for more information. ## Anypoint DataGraph Contract Administration In API Manager, the DataGraph **Contracts** page lists client applications that have requested access, client applications you’ve approved, and client applications whose contracts you have revoked: ![The DataGraph contracts page](/mulesoft/current/en-us/api-manager/latest/_images/datagraph-contracts.png)
1To get additional information about a client application, click the > icon next to the application’s name.
2To revoke an application’s access, click Revoke.

To restore access, click Restore.

## See Also - [Anypoint DataGraph Overview](https://docs.mulesoft.com/datagraph/) - [Permissions For Anypoint DataGraph](https://docs.mulesoft.com/datagraph/permissions) --- product: API Manager version: 2.x is-latest-version: true --- # Managing API Instance Versions > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you publish new version details for an API definition to Exchange, you must update the **Asset version** of your deployed API instances in API Manager to reflect the changes. The API Asset version can only be upgraded or downgraded within the same major version (minor and patch versions). If you need to upgrade to a different major version, you must create a new API Instance. For more information about versions in Exchange, see [Asset Versions](https://docs.mulesoft.com/exchange/asset-versions). To change the asset version of an API instance: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance for which you want to change the version. 3. Select **Actions** > **Change API specification**. 4. In **Asset version**, select your desired version. 5. Click **Change**. ## See Also - [API Instance](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) - [Granting Permission to Access an environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) - [Anypoint Exchange documentation](https://docs.mulesoft.com/exchange/) - [Create an Asset in Exchange](https://docs.mulesoft.com/exchange/to-create-an-asset) - [Delete an Asset in Exchange](https://docs.mulesoft.com/exchange/to-delete-asset) (also describes deprecating an asset) - [About Exchange Portals](https://docs.mulesoft.com/exchange/about-portals) --- product: API Manager version: 2.x is-latest-version: true keywords: instance, manager --- # Managing Instances > For the full documentation index, see: https://docs.mulesoft.com/llms.txt An instance is the instantiation of a definition, such as an API or another component. It is an object that shares data between gateways and the control plane. Depending on its type, an instance can represent a proxy that serves upstream traffic, a Mule application endpoint, or another managed component (for example, a broker, agent, or LLM). You can create, import, and deprecate instances using API Manager. You can use instances in multiple environments, and you can also have multiple instances of the same asset in one environment. For example, you can create one instance of an API version that serves as a proxy and another to directly manage it as an endpoint. You can apply policies based on how the instance is configured — proxy or endpoint. For example, you can apply caching policies to a proxy instance, and throttling or security policies to an endpoint instance. Additionally, you can promote an instance to another environment. To manage instances in API Manager: 1. Add an instance for your relevant gateway: - [Adding a Mule Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-mule) - [Adding an Omni Gateway API Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-flex) - [Adding an Omni Gateway Agent or Tool Instance](https://docs.mulesoft.com/api-manager/latest/create-instance-task-agent-tool) - [Adding an MCP Server from Public Exchange](https://docs.mulesoft.com/api-manager/latest/create-instance-public-exchange) 2. View an instance’s summary for information or to export it: - [Determining API Instance ID on API Manager](https://docs.mulesoft.com/api-manager/latest/find-api-id-task) - API Manager generates the `apiId` of new APIs managed by API Manager for use with Mule 4. - [Exporting an API Instance on API Manager](https://docs.mulesoft.com/api-manager/latest/export-api-latest-task) - After creating an instance, you can export it. This exports the instance configuration and Exchange asset relationship. You can then import it into another environment in the same business group to create a new instance. - [Access Asset and Developer Portals](https://docs.mulesoft.com/api-manager/latest/access-developer-portal-task) - Open the API in Anypoint Exchange from API Manager or from the organization’s public portal to review resources, methods, publish dates, and mocking for the asset. 3. Modify an instance when you no longer need it or when you need to update it: - [Editing an API Instance](https://docs.mulesoft.com/api-manager/latest/edit-api-endpoint-task) - Edit the instance’s configuration settings to update its base path, port, TLS context, and more. - [Deprecating an API instance on API Manager](https://docs.mulesoft.com/api-manager/latest/deprecate-api-latest-task) - While transitioning consumers to an updated instance, you can prevent developers from signing up for access to the old instance. - [Delete API Instances](https://docs.mulesoft.com/api-manager/latest/delete-api-task) - You can delete an instance and its version if you no longer need to manage it from API Manager. - [Managing API Instance Versions](https://docs.mulesoft.com/api-manager/latest/manage-versions-instances-concept) - After you create an asset in Anypoint Platform, you configure the version details and publish it to Anypoint Exchange (Exchange). The version resides in Exchange, and not in API Manager. However, you then manage this version from API Manager. 4. Explore advanced use cases for instances: - [Configure Multiple Client Providers for Client Management](https://docs.mulesoft.com/api-manager/latest/configure-multiple-credential-providers) - You can use multiple client providers, such as OpenAM and PingFederate, to help enforce security and regulations in your business organization. These client providers enable you to secure your operational data, including client credentials and access tokens. - [Governing API Instances](https://docs.mulesoft.com/api-manager/latest/govern-api-instances) - You can govern instances using Anypoint API Governance. View the governance validation report for governed instances to identify conformance issues and take action to fix them. --- product: API Manager version: 2.x is-latest-version: true keywords: oauth, raml, token, validation, policy --- # Meeting Prerequisites for OAuth 2.0 Policies in API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt OAuth 2.0 token enforcement in Anypoint API Manager depends on platform setup, runtime configuration, and API metadata before callers can access protected endpoints. You grant API permissions, attach the OAuth policy to the API instance, register a client application, and use an OAuth 2.0 provider that issues and validates tokens for that client. For RAML-based APIs, define a security scheme when you want API Console to support the OAuth flow; RAML or OAS declarations alone do not attach the policy to the instance. ## Platform and Runtime Prerequisites - Permissions to create or manage APIs - The OAuth 2.0 policy applied to the API instance so the resource is protected - A client application created in API Platform and registered to the API instance - An OAuth 2.0 provider that issues a token from the client credentials and validates it - If you use the Mule OAuth 2.0 provider, configure the runtime with the organization credentials - For RAML-based API instances, specify a security scheme in the RAML when you use API Console with OAuth dance capabilities ## Send Access Tokens to Protected Resources When a resource is protected by an OAuth token enforcement policy, every request must include an OAuth token as a query parameter or in an authorization header. Use either placement consistently; do not send the token in both places at once.
Places to include TokenExampleNotes

Query parameter

?access_token=123

Included as part of the URI

Authorization header

Authorization:Bearer 123

The header consists of a key:value pair, where Authorization is the key and the value is composed as follows: "Bearer" + <space> + <token, for example, 123>

## Declare OAuth Protection in RAML For RAML-based API instances, mark resources and methods as secured by OAuth so API Console reflects the intended protection. > [!IMPORTANT] Declaring OAuth Token Enforcement in your RAML or OAS definition does not apply the > policy to the API instance. In the `securitySchemes` definition, set URIs for authorization and the access token. Add `securedBy` on each resource and method you want to secure. ```yaml #%RAML 1.0 title: Interop Testing version: v1.0 baseUri: http://127.0.0.1:8081/api ... securitySchemes: oauth_2_0: description: | Mule OAuth 2.0. type: OAuth 2.0 describedBy: headers: Authorization: description: | Used to send a valid OAuth 2 access token. Do not use with the "access_token" query string parameter. type: string queryParameters: access_token: description: | Used to send a valid OAuth 2 access token. Do not use together with the "Authorization" header type: string responses: 401: description: | Bad or expired token. 403: description: | Bad OAuth request. settings: authorizationUri: http://0.0.0.0:8081/authorize accessTokenUri: http://0.0.0.0:8081/access-token authorizationGrants: [authorization_code, password, client_credentials, implicit] ... /users: get: securedBy: [oauth_2_0] ``` ## See Also - [RAML securitySchemes](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md#oauth-20) --- product: API Manager version: 2.x is-latest-version: true keywords: migrate client applications, migrate applications, migrate --- # Migrate Client Applications > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You might have application client credentials residing outside of Anypoint Platform if you were previously using a different API management solution. You must first migrate those client applications to Anypoint Platform, with their client ID and client secret credentials, before you can start using the credentials in Anypoint Platform. Your client applications can consume APIs whose organization is associated to an Anypoint Platform client provider or an external client provider. The instructions for these two scenarios differ: - [Migrate client applications for APIs with Anypoint Platform client providers](#migrate_with_internal) - [Migrate client applications for APIs with external client providers](#migrate_with_external) ## Prerequisites Before migrating the client application, ensure that you: - Obtain the required token and credentials: - Client ID and client secret for the client application to migrate - Anypoint Platform [token](https://dev-portal.mulesoft.com/apis/access-management.html) - Review the [scope and limitations](#considerations) ## Scope and Limitations Before you migrate your client applications to Anypoint Platform, review the following scope and limitations: - Do not attempt to update the client ID and client secret of your application. This feature is not supported. - Because client IDs are unique in Anypoint Platform, do not reuse the same client ID in two different accounts. To avoid the duplication, specify unique client IDs for your accounts. - Do not use the same user to create more than 500 applications. - Do not create applications with duplicate names. - Do not attempt to refresh the client ID unless you first delete and then re-register the client application. - If the client credentials you provide match the credentials of an existing organization ID on the client provider, the application is associated with that client. Conversely, if the client credentials that you provide do not match, the client application is created with no association to existing clients. ## Migrate Client Applications for APIs with Anypoint Platform Client Providers To migrate your client application: 1. Open a text editor and paste the following commands: ```text curl --location --request POST 'https://anypoint.mulesoft.com/exchange/api/v1/organizations/:orgId/applications' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "clientId": , "clientSecret": , "grantTypes": [], "name": , "redirectUri": [] }' ``` 2. Replace the `orgId` parameter with the ID of your root organization and the content of the body with the appropriate application [properties](#properties). 3. Run this command at the command prompt. ## Migrate Client Applications for APIs with External Client Providers When creating an application for an organization with registered external client providers, you can directly associate the application with the API that you want to consume, using that API instance ID (available from the API Manager UI). If you use a PingFederate external client provider or the Anypoint Platform client provider, you can include the client ID and client secret when referencing an API. Otherwise, for providers like Okta or Keycloak, which are registered using OpenID Dynamic Client registration, you cannot define client ID and client secret credentials. To migrate your client application: 1. Open a text editor and paste the following commands: ```text curl --location --request POST 'https://anypoint.mulesoft.com/exchange/api/v1/organizations/:orgId/applications?apiInstanceId=:myApiInstanceId' \ --header 'Authorization: Bearer ' \ --header 'Content-Type: application/json' \ --data-raw '{ "clientId": , "clientSecret": , "grantTypes": [ ], "name": , "redirectUri": [ "https://anypoint.mulesoft.com/apiplatform/:orgId/authentication/oauth2.html", "https://anypoint.mulesoft.com/apiplatform/:orgId/admin/authentication/oauth2.html", ] }' ``` 2. In the command snippet, replace the `orgId` parameter with your organization ID, `apiInstanceId` with the API instance ID, and the content of the body with the appropriate application [properties](#properties). > [!IMPORTANT] The API instance ID must be configured to use the external client provider before > running this command. If you need to change the client provider on an existing API instance, > delete all existing contracts for that instance first. 3. Run this command at the command prompt. ## Migrate Command Properties Reference In the properties of the migrate command, provide values based on the following recommendations: - `clientId`: - `clientSecret`: - (optional)`description`: This property is displayed on the application page. - `name`: This property is displayed when selecting an application before requesting access. - `redirectUri`: - (optional) `url`: This property is displayed on the application page. - `grantTypes`: - `Resource Owner Grant`: "password" - `Implicit Grant`: "implicit" - `Client Credentials Grant` "client\_credentials" - `Authorization Code`: "authorization\_code" - `Refresh Token`: "refresh\_token" (Authorization Code must be present to use this grant type.) For more information about which grant types your external client provider supports, see your client provider documentation. --- product: API Manager version: 2.x is-latest-version: true --- # Modify API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If your business requirements change, you might want to modify an API Group by adding new API instances to it. To cover new scenarios, you might want to add a new API instance. You can also version an existing instance to add customizations. If a service is no longer required, you can remove the respective API instance that supports the service. However, modifying API Groups and API Group instances involves specific [restrictions](#restrictions). When you publish an API Group in Exchange, the [status](#exchange_status) of the API Group changes based on specific scenarios. ## Restrictions for Modifying API Group and Instances Before you modify an API Group, ensure that you carefully review the restrictions: - Add new instances of APIs that already exist in the group only if the API Group instance has no contracts. - Add only API instances that belong to the same identity provider (IdP). You cannot mix IdPs in an API Group instance. - Add API instances but not APIs if: - The API Group instance is published. - The API Group version is published. - The API Group version has multiple API Group instances. ## Exchange Status Based on API Group Transactions The Exchange status of an API Group depends on these conditions: - If your API Group is published in Exchange, your Exchange asset displays the new API instance. - If the API instance you added is related to an asset that is already linked to the Exchange API Groups asset, the API instance displays these details. - If the API instance you added belongs to a new asset that is not yet liked to the Exchange API Groups asset, customers must create a new version of the API Groups asset. ## Task Prerequisites Before you begin, you must have: - At least one API instance in your organization or business group Otherwise, you will not be able to find the required organization or business group in the list. - API Group Administrator permissions to add API instances to an API Group ## Add API Instances to Existing API Groups You might want to add API instances to an existing API Group to widen the business problem it solves. To add API instances to an existing API Group: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. On the API Groups details page, expand the API Group to view its available versions. 4. Click **Add group instance** for the version of the API Group that you want to add the API instance to. The **Creating a new group instance** page is displayed. 5. Click **+Add**. 6. If the API instance and the API Group belong to the same business group or organization, select the API, API version, environment, and API version/instance to add to the API Group. 7. If the API instance and the API Group belong to different business groups: 1. Click **Add Organization**. 2. Select the organization or business group in which your API instance is available and click **Add**. 3. Select the environment, API instance, and version that you want to add. 8. Click **Save**. Your API instances are now added to the API Group. To publish your API Group in Exchange, see [Publishing API Groups to Exchange](https://docs.mulesoft.com/api-manager/latest/api-groups-publishing-to-exchange). ## Remove API Instances from API Groups If your business requirements change, you might want to modify an API Group by removing an existing API instance. To remove an API instance from an API Group: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. On the API Groups page, expand the API Group to view its available versions. 4. Expand the API Group version to view its available instances. 5. Click the API Group instance to view the instance details. 6. Click the more options menu icon ( ![overflow menu icon](/mulesoft/current/en-us/api-manager/latest/_images/overflow-menu-icon.png "Screenshot of the more options menu icon") ) next to **Edit** and select **Delete**. > [!NOTE] If the API instance you removed is the last API linked to an asset, you must create a > new version of the API Group. 7. Click the checkbox to acknowledge that you understand **this action can’t be undone** then click **Delete Group instance**. ## Create API Group Versions If you modify an API Group to add a new API or delete an existing API based on changing business requirements, you might need to version the API Group appropriately. To create additional versions of an API Group: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. Click **Add group version** for the API Group. 4. In the **API Group Version** field, specify the version number that you want to create: for example, `v1.1` or `v2.0`. 5. In the **API Group instance label** field, enter a label to uniquely identify this instance of the group. 6. Click **Continue**. . 7. Add API instances in the API Groups. The API Group is prepopulated with the existing instances from the previous version. For more information about how to add API instances to an API Group, see [Adding API Instances to Existing Groups](#adding-api-instances-to-groups). 8. Click **Save**. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Create Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-creating-groups) - [Publish API Groups to Exchange](https://docs.mulesoft.com/api-manager/latest/api-groups-publishing-to-exchange) - [Deprecate Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deprecating-groups) --- product: API Manager version: 2.x is-latest-version: true keywords: analytics --- # Mule API Analytics > For the full documentation index, see: https://docs.mulesoft.com/llms.txt > [!NOTE] **Mule API Analytics** does not support Omni Gateway APIs. For Omni Gateway Analytics, see > [Viewing Key Metrics in API Manager for Omni Gateway in Connected Mode](https://docs.mulesoft.com/gateway/latest/conn-view-api-metrics). Mule API Analytics can provide insight into how your Mule APIs are being used and how they are performing. From API Manager, you can access the Mule API Analytics dashboard, create a custom dashboard, create and manage charts, and create reports. From API Manager, you can get following types of analytics: - API viewing analytics - API events analytics - Charted metrics in API Manager You can view data from a policy perspective in the Mule API Analytics dashboard, Mule API Analytics chart, or API Manager by including policy violations. This action tracks traffic rejected, or not rejected, by a policy. The **Mule API Analytics** tab is visible only to users who have `Read API` permission. Charts are visible for users who have `View Analytics` permission. > [!NOTE] API Analytics isn’t available on Hyperforce deployments. ## See Also - [Reviewing Analytics usage](https://docs.mulesoft.com/api-manager/latest/viewing-api-analytics) - [View Mule API Analytics Charts in API Manager](https://docs.mulesoft.com/api-manager/latest/analytics-chart) - [Generate Mule API Analytics Reports with the Event API](https://docs.mulesoft.com/api-manager/latest/analytics-event-api) - [Forward Mule API Analytics Events to External Systems](https://docs.mulesoft.com/api-manager/latest/analytics-event-forward) --- product: API Manager version: 2.x is-latest-version: true --- # OAuth 2.0 Dance and OAuth 2.0 Access Token Enforcement > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The OAuth dance is the authentication process performed by the Mule OAuth 2.0 provider, API, and client application. This authentication process conforms to RFC 6749. ## OAuth Dance Authentication Flow The OAuth dance authentication flow is illustrated in the following screenshot: ![oauth+policy1](/mulesoft/current/en-us/api-manager/latest/_images/mule-oauth-provider-dance.png) 1. A token request is sent to the provider, specifying client application credentials as needed. The credentials correspond to a client ID and secret generated by Anypoint Platform. 2. The Mule OAuth 2.0 provider returns a token. 3. An HTTP request is performed against the protected resource to which the OAuth 2.0 Access Token Enforcement policy is applied. The protected resource must be linked with the API definition through Autodiscovery. 4. The OAuth 2.0 Access Token Enforcement policy intercepts this request and communicates with the provider to validate the token. 5. If the token is correctly validated: 1. The token is allowlisted and kept on the record until it expires. Any further request that contains this token is not validated against the OAuth provider. 2. The associated client ID of the client application credentials is verified to ensure that the application has an active contract with the API. This is not applicable to OpenAM providers. 6. The request is then forwarded to the resource. 7. An HTTP response is generated. The requester obtains the authorization from an OAuth provider, instead of directly gaining access to the credentials of the client application. The client application owner owns the credentials and authorizes the provider to interact with the API. The protected resource determines that the user is authorized because it has a valid access token. ## Example HTTP Request to a Protected Resource Using curl In the following example, the protected resource is set to `[http://localhost:8081/simple](http://localhost:8081/simple)`. ### Using an HTTP Authorization Header ```console curl -H "Authorization:Bearer " "http://localhost:8081/simple" -vvv ``` ### Using an HTTP Query Parameter ```console curl "http://localhost:8081/simple/?access_token=" -vvv ``` ## See Also - [OAuth 2.0 Grant Types](https://docs.mulesoft.com/api-manager/latest/oauth-grant-types-about) - [Mule OAuth 2.0 Provider](https://docs.mulesoft.com/api-manager/latest/mule-oauth-provider-landing-page) --- product: API Manager version: 2.x is-latest-version: true --- # OAuth 2.0 Grant Types > For the full documentation index, see: https://docs.mulesoft.com/llms.txt OAuth 2.0 specifies the following grant type methods for requesting a token: - AUTHORIZATION\_CODE - IMPLICIT - RESOURCE\_OWNER\_PASSWORD\_CREDENTIALS - CLIENT\_CREDENTIALS For RAML-based APIs, you must update the RAML to match the OAuth 2.0 security schema. The following table maps the RAML grant types to grant type names in the OAuth 2.0 policy configuration:
Authorization Grant Types Defined in RAML DefinitionEquivalent Authorization Grant Type to Enable in the OAuth Provider PolicySupported in embedded APIkit Console?

[implicit]

Implicit

Yes

[client_credentials]

Client Credentials

No

[password]

Resource Owner Password Credentials

No

[authorization_code]

Authorization Code

Yes

[Reviewing OAuth 2.0 Policy Prerequisites](https://docs.mulesoft.com/api-manager/latest/about-configure-api-for-oauth) document has additional details about this. ## Authorization Code Grant Type The Authorization Code grant type is the most frequently used grant type and the most secure. To get a token using this grant type, the following information needs to be specified in the HTTP request to the Provider: - Client ID of the client application - Client Secret of the client application - Redirect URL as specified on the client application definition ### HTTP request example against the provider to get a token Assuming that the provider is accessible on `http://localhost:8081` and the redirect URL of your client application is `http://localhost:1234`: Request authorization: ```console curl “http://localhost:8081/authorize” \ -d “response_type=code&client_id= \ &scope=&redirect_uri=http://localhost:1234” \ -X POST ``` The login page appears in the browser. After the user logs in, the provider sends a redirect to the `redirect_uri`. This redirect includes additional properties, including an access code. Response: http://localhost:1234/?code=#/login Send the access code to the token endpoint in a request that also includes the client ID, the client secret and some of the information in the previous call: Request token: ```console curl “http://localhost:8081/access-token” \ -d “grant_type=authorization_code&client_id=&client_secret= \ &code=&redirect_uri=” \ -X POST ``` JSon Response: { "expires\_in":86400, "token\_type":"bearer", "refresh\_token":"", "access\_token":"" } ## Implicit The implicit grant type is not as secure as, but easier to use than the authorization code grant type. Javascript clients and mobile applications often use this grant type. The authorization server issues an access token directly and skips the step of issuing an intermediate access code. ### HTTP request example against the provider to get a token Assuming that the provider is accessible on `http://localhost:8081` and the redirect URL of your client application is `http://localhost:1234`: Invoke the authorization endpoint with a request that includes the client ID, the type of authorization you want to perform, the redirect URL, and the scopes you want to authorize. The structure of the request should look like the URI below: Request token: ```console curl “http://localhost:8081/authorize” \ -d “grant_type=implicit&client_id= \ &redirect_uri=http://localhost:1234&response_type=token” \ -X POST ``` This displays the login page in the browser. After the user logs in, the provider sends a redirect to the `redirect_uri`. This redirect already includes the token, not just an access code: Response: http://localhost:1234/#access\_token=&token\_type=bearer&expires\_in=86400 ## Resource Owner Password Credentials The resource owner password credentials grant type is less secure than both the implicit and the authorization code grant types. The client needs to handle the user’s credentials. This requires that users have a high degree of trust in the client. This grant type is often used when the consumer of the protected resource is a widget of the same service. ### HTTP request example against the provider to get a token Assuming that the provider is accessible on `http://localhost:8081`: Send a POST request to the token endpoint that includes the user name and password: Request token: ```console curl "http://localhost:8081/access-token” \ -d “grant_type=password&response_type=token&username= \ &password=&client_id= \ &client_secret=" \ -X POST ``` JSon Response Example: ```json { "expires_in": 86400, "token_type": "bearer", "refresh_token": "", "access_token": "" } ``` ## Client Credentials The client credentials grant type is the least secure grant type. Use this grant type when the client is the resource owner or an authorization has previously been arranged with the authorization server. In this grant type, an access token is obtained if the client identifier and the client secret are valid. ### HTTP request example against the provider to get a token Assuming that the provider is accessible on `http://localhost:8081` and the redirect URL of your client application is `http://localhost:1234`: Send a POST request to the token endpoint that includes the user name and password: Request token: ```console curl “http://localhost:8081/access-token” \ -d “grant_type=client_credentials&client_id= \ &client_secret=&response_type=token” \ -X POST ``` JSon Response: http://localhost:1234/#access\_token=&token\_type=bearer&expires\_in=86400 ## See Also - [Mule OAuth 2.0 Provider](https://docs.mulesoft.com/api-manager/latest/mule-oauth-provider-landing-page) --- product: API Manager version: 2.x is-latest-version: true --- # Obtaining the Client Credentials of a Registered Client Application > For the full documentation index, see: https://docs.mulesoft.com/llms.txt As the owner of a [registered client application](https://docs.mulesoft.com/exchange/to-request-access), you are occasionally required to provide your client ID and client secret when accessing an API, after a contract is created between your application and an API. You are required to provide the client ID and client secret credentials depending on the policies applied to that API. For example, if the API owner has applied the Client ID Enforcement policy, you must provide your application’s client ID and, optionally, its client secret to access the API. You must have the Organization Administrator privileges of the root organization, or must be the owner of the client application to access the credentials. To obtain the credentials of a client application: 1. Go to **Anypoint Platform** > **API Manager**. 2. Click **Client Applications**. 3. From the details pane, click the application for which you want to view the client credentials. The client ID and client secret credentials for the selected application appear in the window. 4. Alternatively, if you need to obtain only the client ID of the registered client application, select the correct version of the API and click **Contracts**. As an Application Owner, if you do not have access to API Manager, you can view the [application credentials](https://docs.mulesoft.com/exchange/about-my-applications) in Exchange. 5. To view the details, click the specific API contract. ## See Also - [Registering a Client Application](https://docs.mulesoft.com/exchange/to-request-access) [https://docs.mulesoft.com/exchange/about-my-applications](https://docs.mulesoft.com/exchange/about-my-applications) --- product: API Manager version: 2.x is-latest-version: true --- # Policy Packaging, Scope, and Size > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A policy consists of the following things: - A YAML file Defines the configurable parameters of the policy. Rendered by the UI to display the input of the policy. - An XML template Contains the implementation of the policy. - The template’s POM Defines policy dependencies. Packaging type needs to be `mule-policy`. - Resources Optionally if the policy depends on other resources, such as a certificate, define resources as part of the policy. - The mule-artifact.json descriptor Specify the classifier as `mule-policy`. For more information, see the header policy. ## Policy Scope Policies are isolated from the application and other policies, however there are ways to expose information from a policy. The authentication information about a policy can be propagated in the Security Context Principal object. A policy can modify message content. In Mule 4.1.0 and later, if the message is modified before the `execute-next` in `source` policies or after it in `operation` policies, those modifications are not propagated by default. To enable propagation of those modifications you can enable the `propagateMessageTransformations` flag in each policy. **Example** A policy can avoid the execution of the flow by not defining the `execute-next` or making sure that it is not reached (placing it in a choice, for example). Variables set on a policy have only the scope of the policy. Also, variables defined in the flow, are not visible in policies. ## Policy Size The size of a policy varies based on its dependencies. The first time Mule Runtime polls for policies it will take longer to fetch them. However, after policies are retrieved, they are cached on the file system. This ensures offline availability and also reduces latency to fetch policies. ## See Also - [Policies](https://docs.mulesoft.com/gateway/latest/gateway-secure-apis) --- product: API Manager version: 2.x is-latest-version: true --- # Prepare Your Environment for Agent Verification > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before verifying an agent using GoDaddy Agent Name Service (ANS), configure your environment to support domain-based identity validation. Verification requires a custom domain, a configured runtime environment, and secure communication settings. ## Custom Domain Agent verification requires a custom domain (vanity domain) that you own and control. - The domain associated with your agent must match the consumer endpoint used during registration. - The domain is used to establish the agent’s identity. - You must be able to create and manage DNS records for the domain. - MuleSoft-managed domains such as `cloudhub.io` aren’t supported. ## Private Space Deploy agents in a private space that supports custom domains and TLS configuration. If you don’t already have a private space, create one in Runtime Manager before proceeding. For more information, see [Private Spaces](https://docs.mulesoft.com/cloudhub-2/ps-manage). ## TLS Context Configure a TLS context in your private space for the domain used by the agent. TLS configuration enables secure communication and is required to complete verification. A TLS context must be configured for the domain used by the agent. API Manager requires a valid TLS context for the domain before verification can proceed. To configure a TLS context: 1. In Anypoint Platform, go to **Runtime Manager**. 2. Select your private space. 3. Open the **TLS** or **Domains and TLS** section. 4. Create a new TLS context for your domain. 5. Upload a valid certificate for the domain. Make sure that: - The TLS context is associated with your domain - The certificate is valid and active - The domain matches the consumer endpoint used by the agent If no TLS context is configured, verification can’t proceed and an error is displayed. For more information, see [Configure domains and TLS certificates](https://docs.mulesoft.com/cloudhub-2/ps-config-domains) ## Gateway Configuration Agents must be exposed through a configured gateway to support domain-based verification. When using Flex Gateway, you must configure an endpoint for each agent using your custom domain. For setup instructions, see [Set up Flex Gateway in managed mode](https://docs.mulesoft.com/gateway/latest/gateway-managed-set-up). Make sure that: - Each agent is mapped to a unique endpoint or path in the gateway configuration - The endpoint uses the same domain as the agent’s consumer endpoint > [!NOTE] Each agent must be configured with a separate endpoint in the gateway. > > If multiple agents are deployed on the same domain, each one requires its own explicit endpoint > configuration. ## Secret Group Access Agent verification requires access to a secret group in Secrets Manager. The secret group is used to store generated security artifacts during verification. Make sure that: - At least one secret group exists - You have permission to write to the selected secret group If you don’t have the required permissions, you can’t complete verification. > [!IMPORTANT] If the domain, TLS context, and gateway configuration aren’t aligned, agent > verification can’t be completed. ## Next Steps After completing the environment setup: - [Create an agent instance](https://docs.mulesoft.com/api-manager/latest/godaddy-register-agent) - [Verify an agent using GoDaddy ANS](https://docs.mulesoft.com/api-manager/latest/godaddy-verify-agent) --- product: API Manager version: 2.x is-latest-version: true --- # Promote API Instances in API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can promote an API Group instance from one environment to another, for example, sandbox to production. When you promote an API Group instance, the source environment of the instance remains unchanged. However, the destination environment changes by creating the API Group instance that is being promoted. The API instances of the promoted API Group instance might differ from the original group instance, but the definition (related assets) remains the same. ## Task Prerequisites Before you begin, ensure that you have: - Obtained the API Group Administrator permissions to be able to promote an API Group instance - Verify that the APIs in the API Group instance that you want to promote are already present in the destination environment For example, if the API Group instance that you want to promote contains the Facebook API, the destination environment must already have the Facebook API in that environment type. To promote an API Group instance: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups** > **Promote from environment**. 3. From the **Source Environment** list, select the environment of the API you want to promote. 4. From the **API Group** list, select the API Group to which the API instance belongs. 5. From the **API Group version** list, select the version of the API Group to which the instance belongs. 6. From the **API Group instance** list, select the API Group instance that you want to promote. 7. Optionally, select the **Import default limits from existent SLA Tiers** checkbox if you want to include the SLA tiers when promoting from source to destination environment. Note that only the default limits of every tier is promoted. 8. Click **Promote**. --- product: API Manager version: 2.x is-latest-version: true --- # Promoting an API Instance to Another Environment > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Before promoting an API instance to another environment, ensure that you have the `Manage APIs Configuration` permission. To promote an entity, you must have permissions to view and manage the entity. For example, you must have the `View Policies` and `Manage Policies` permissions to promote a policy. ## Promote an API Instance from Another Environment 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click **Add API** and select **Promote API from environment**. 3. Select the **Source Environment**. 4. Select the **API** by entering the name of the API into the search field. 5. Select the **API Version**. 6. Select the **API instance label**. 7. Optionally, uncheck any of the **Include in Promotion** options you want to exclude. 8. Click **Promote**. 9. Review and update the Runtime & Endpoint Configuration details as needed and click **Save**. Promoting an API instance affects only the API definition, not the existing deployed applications subscribed to the instance. After promoting an API, the **API Label** remains the same, but the **API Instance ID** changes. For existing applications that must subscribe to a promoted API instance: 1. Update the **API Instance ID** within the application. 2. Update the application’s client ID and secret (because each environment has a different client ID and secret). ## See Also - [Granting Permission to Access an environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) - [Environments](https://docs.mulesoft.com/access-management/environments) - [Creating an API instance on API Manager](https://docs.mulesoft.com/api-manager/latest/api-instance-landing-page) --- product: API Manager version: 2.x is-latest-version: true --- # Publish API Groups to Exchange > For the full documentation index, see: https://docs.mulesoft.com/llms.txt After you create or edit an API Group to add the required API instances, you publish the API Group to Exchange to make it available to consumers. ## Task Prerequisites Before you begin, ensure that you have permissions to all the assets in the API Group instance in Exchange. ### To publish API Groups to Exchange: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. From the API Groups details page, click the **API Group version** that you want to publish and click the **API Group instance**. The API Group instance page is displayed: ![Publishing API Groups to Exchange](/mulesoft/current/en-us/api-manager/latest/_images/publish-api-product-to-exchange.png) 4. If the instance is not already published to Exchange, the **Publish to Exchange** button appears on the page. 5. Click **Publish to Exchange**. 6. On the **Publish** window, specify the name for the API Group asset and the version. 7. Click **Publish**. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Create Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-creating-groups) - [Modify Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-modifying-groups) - [Deprecate Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deprecating-groups) - [Delete API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-deleting-groups) --- product: API Manager version: 2.x is-latest-version: true --- # Register Agents with GoDaddy ANS > For the full documentation index, see: https://docs.mulesoft.com/llms.txt GoDaddy Agent Name Service (ANS) integration enables you to register and verify agents deployed through API Manager. Registration associates an agent with a fully qualified domain name (FQDN) and establishes a verifiable identity based on domain ownership. This identity is used across Anypoint Platform to indicate whether an agent is trusted and verified. This integration connects API Manager with GoDaddy to validate domain ownership and manage verification status. ## Capabilities With GoDaddy ANS integration in API Manager, you can: - Register an agent instance with GoDaddy ANS - Verify agent identity using domain ownership validation - Track verification progress directly from API Manager - View verification status in Anypoint Exchange ## Registration Workflow The registration workflow spans API Manager, GoDaddy, and your DNS provider. Initiate registration from an API instance in API Manager. GoDaddy validates domain ownership using standard verification methods such as DNS or ACME challenges. API Manager tracks the verification process and updates the agent status when verification is complete. Depending on your domain configuration, some steps might require manual action. ## Consumer Endpoint and FQDN The consumer endpoint configured for the agent is used to derive a fully qualified domain name (FQDN) that uniquely identifies the agent. Only the hostname of the endpoint is used. For example, in `[https://example.com/path](https://example.com/path)`, the registered domain is `example.com`. This domain is registered as part of the verification process and can’t be modified after registration. For more information, see [What is a Fully Qualified Domain Name (FQDN)?](https://www.godaddy.com/resources/skills/whats-a-fully-qualified-domain-name-fqdn-and-whats-it-good-for). ## Domain Requirements The domain used for registration must meet these requirements: - Be a custom domain (vanity domain) - Not be a MuleSoft-managed domain such as `cloudhub.io`, as these domains aren’t supported - Be associated with a valid DNS configuration If these requirements aren’t met, registration can’t proceed. ## Integration with Anypoint Exchange Verification status is reflected in Anypoint Exchange: - Verified agents display a visual indicator in search results and asset pages - Verification is tied to the agent instance and its associated domain ## Next Steps Before registering an agent, ensure that your environment is properly configured. For more information, see [Prepare Your Environment for Agent Verification](https://docs.mulesoft.com/api-manager/latest/godaddy-set-up). ## See Also - [API Manager Overview](https://docs.mulesoft.com/api-manager/latest/) - [Anypoint Exchange](https://docs.mulesoft.com/exchange/) --- product: API Manager version: 2.x is-latest-version: true --- # Remove SLA Tiers from API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can remove an SLA tier from an API Group instance if you no longer need it. To remove an SLA tier: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **API Groups**. 3. Expand the API Group list and click the API Group instance to which you want to add the SLA tier. 4. Click **SLA Tiers**: 5. From the API Group instance details page, click the ellipses button in the SLA tier list and click **Delete**. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Add SLA Tiers to API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-add-sla-tiers) --- product: API Manager version: 2.x is-latest-version: true keywords: alerts, instance, api alerts, contracts --- # Reviewing Alerts Concepts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Anypoint Platform alerts you about request behavior, performance issues, actions related to client application contracts, and runtime events. The platform supports three types of alerts: - Instance alerts - Contracts alerts - Runtime alerts Instance alerts and contracts alerts are managed by Anypoint API Monitoring. Runtime alerts are managed by Anypoint Runtime Manager (Runtime Manager). Refer to [Using Omni Gateway API Alerts](https://docs.mulesoft.com/gateway/latest/use-api-alerts) to learn how to use the new API Monitoring alerts. > [!NOTE] Alerts aren’t available on Hyperforce deployments. ## Instance Alerts Add and configure instance alerts that flag unusual behavior, such as: - A response time over 60 seconds - More than 1000 requests in 30 seconds See [Add Instance Alerts in API Manager (Mule Gateway)](https://docs.mulesoft.com/api-manager/latest/add-api-alert-task). API Manager enables you to add alerts to different types of instances: - For **API instances**: - **Policy Violation** An infraction of one or more policies governing the API occurs. - **Request Count** Users request access to the API more times than allowed in a specified interval of time. Specify time interval values from 1 through 999999999. To prevent data bursts, intervals are implemented as sliding windows instead of as absolute minute boundaries. See [Sliding Windows](https://www.techopedia.com/definition/869/sliding-window). - **Response Code** The API returns one of these HTTP codes upon receiving a request: 400, 401, 403, 404, 408, 500, 502, or 503. - **Response Time** The response time of the API exceeds a specified timeout period. - For **Agent Fabric assets (agents, MCP servers, LLMs)**: - Availability or connectivity issues. - Broker or agent failure events. - Processing delays or exceeded capacity thresholds. Instance alerts are triggered only when states change, although the first occurrence of a state change might be undetected due to newly created alerts not having defined states. When configuring an instance alert, you select Business Group users to receive email notifications about the alert. Notifications include information about events that trigger alerts as specified by severity level. Users receive the following: - One email describes the alert: `Your API, CesarDemoAPI - Basic:151 (Environment: "NewOne"), has received greater than 2 requests within 1 consecutive periods of 1 minute.` - Another email notifies you when the alert is resolved: `Your API Version, jsonplaceholderapi - 1.0.development, is no longer in an alert state. The number of policy violations was not greater than 1 in the last 1 consecutive periods of 1 minute.` After an alert is triggered, API Manager sends the first set of two notification emails and stops listening for alerts until the next alert period begins. This technique prevents repeated notification emails. > [!NOTE] Alerts are sent from `no-reply@mulesoft.com`. This cannot be customized. The alert email can be sent before the corresponding sliding window has fully closed. Although the alert condition is evaluated based on the sliding window, the condition may be met before all metrics for the window arrive. For example: If the alert condition is set to "error count > 1 in a 5-minute window" and 10 errors occur within the first minute, the alert email is sent during that first minute, even though the sliding window continues to accumulate metrics for the remaining 4 minutes. ## Contracts Alerts API Manager automatically notifies users when actions related to contracts occur. For instance, when a client application requests access to an instance, API Manager sends a notification with the status of the request. Depending on the configuration, status might indicate that the request is pending manual approval, or it might indicate that the request has been auto-approved. The following actions trigger contracts alerts:
Table 1. Contracts
ActionRecipientDescription

Contract approved

Client application owners

User is notified that request access was approved.

Contract auto-approved

Organization administrators, environment administrators, contracts managers

User is notified that request access was auto-approved.

Contract pending

Organization administrators, environment administrators, contracts managers

User is notified that request access is pending.

Pending contract rejected

Client application owners

User is notified that request access was rejected.

Revoked contract restored

Client application owners

User is notified that request access was restored.

Approved contract revoked

Client application owners

User is notified that request access was revoked.

Contract tier changed

Client application owners

User is notified that the contract tier was changed.

Requested contract tier change approved

Client application owners

User is notified that a requested tier change was approved.

Requested contract tier change rejected

Client application owners

User is notified that a requested tier change was rejected.

Contract tier change requested

Organization administrators, environment administrators, contracts managers

User is notified that a contract tier change is pending review.

Table 2. Group Contracts
ActionRecipientDescription

Contract approved

Client application owners

User is notified that request access was approved.

Contract auto-approved

Group administrators

User is notified that request access was auto-approved.

Approved contract revoked

Client application owners

User is notified that request access was revoked.

Revoked contract restored

Client application owners

User is notified that request access was restored.

Pending contract rejected

Client application owners

User is notified that request access was rejected.

Contract pending

Group administrators

User is notified that request access is pending.

Contract tier changed

Client application owners

User is notified that a contract tier change is pending review.

Requested contract tier change approved

Client application owners

User is notified that a requested tier change was approved.

Requested contract tier change rejected

Client application owners

User is notified that a requested tier change was rejected.

Contract tier change requested

Group administrators

User is notified that a contract tier change is pending review.

> [!NOTE] Contracts Alerts are sent from `no-reply@mulesoft.com`. This cannot be customized. ## Runtime Alerts Alerts in Runtime Manager differ from API alerts and contracts alerts. For example, Runtime Manager flags CPU usage, secure data gateway status, and deployment success or failure. See [Alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager). ## Omni Gateway Alerts Alerts for Omni Gateway differ from API alerts and contract alerts. For example, Omni Gateway includes **Alert Logic** options and the ability to customize the subject and message of **Email notifications**. See [Using Omni Gateway API Alerts](https://docs.mulesoft.com/gateway/latest/use-api-alerts) for more information. ## Alert Rate Limits Anypoint Platform enforces rate limits that determine how often an alert is triggered, and how often email notifications are sent. See [Rate Limits on Alerts](https://docs.mulesoft.com/runtime-manager/alerts-on-runtime-manager#rate-limits-on-alerts) for information on enforced limits. ## See Also - [Add Instance Alerts in API Manager (Mule Gateway)](https://docs.mulesoft.com/api-manager/latest/add-api-alert-task) - [Testing an API Alert](https://docs.mulesoft.com/api-manager/latest/test-alert-task) - [Viewing and Deleting API Alerts](https://docs.mulesoft.com/api-manager/latest/view-delete-alerts-task) - [Editing, Enabling, or Disabling API Alerts](https://docs.mulesoft.com/api-manager/latest/edit-enable-disable-alerts-task) --- product: API Manager version: 2.x is-latest-version: true --- # Reviewing API Proxy Benefits and Impacts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The tables below describe the main benefits and impacts of implementing the different types of API Proxies. ## Benefits
BenefitWSDLRAML/OASHTTPHTTPS

Tracks proxy in API Manager and generates Mule API analytics. Requires Autodiscovery.

yes

yes

yes

yes

Applies policies for API governance.

yes

yes

yes

yes

Sends errors related to MuleSoft-provided policies as soap:fault messages

yes

no

no

no

Includes API Console for simulating API requests.

By default, you can open API Console using a URL in the format: <host_of_your_proxy>:<port_of_your_proxy>/console

no

yes

no

no

## Impacts These are the impacts on your requests going through your API proxies.
ImpactWSDLRAML/OASHTTPHTTPS

Includes X-Forwarded-For headers.

yes

yes

yes

yes

Sends received headers to implementation API except Mule-included ones.

Mule-included headers are, for example, X-MULE-SESSION, and X-MULE-ENCODING, among others.

yes

yes

yes

yes

Validates headers, body, URI, query, and form parameters API against RAML 0.8/1.0.

no

yes

no

no

Provides default parameter values if specified in RAML but absent from request.

no

yes

no

no

Handles a secure connection using the keystore and truststore provided in the TLS configuration for server authentication.

no

no

no

yes

## See Also - [API Console - To Simulate API Calls](https://docs.mulesoft.com/apikit/latest/apikit-4-implement-rest-api) --- product: API Manager version: 2.x is-latest-version: true --- # Reviewing Environment Concepts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt The support for environments in strategic components of Anypoint Platform eliminates the need to construct version names to reflect an environment. The administrator grants permissions per environment. A user who is granted environment access permission has full access to operations inside the specific environment: ![API Manager API Administration with the environment sandbox selected.](/mulesoft/current/en-us/api-manager/latest/_images/environment3.png) API Manager environment administrator only relates to actions inside of API Manager. The API Manager Environment Administration permission allows you to do the following things: - Create and modify your APIs as well as modifying those created by others - Apply policies - Define SLAs - Create alerts As organization administrator, you grant permissions to users as described in the topic linked below. When you navigate to API Manager, you see the environment control bearing the name of your default environment. In this example, Sandbox is the default environment: ![API Manager API Administration with the environment sandbox selected.](/mulesoft/current/en-us/api-manager/latest/_images/environment3.png) When you click the environment control, a list of your production and sandbox environments appears. To connect Mule Runtime to API Manager through Autodiscovery, you need to provide the one of the following credential pairs: - The client ID and secret of the environment - The client ID and secret of the organization where you registered the API - The client ID and secret of the parent of the organization where you registered the API. For example, you can have a parent business group(BG) for ABC Corp, and that parent can have children ABC-BG1 and ABC-BG2. You can track the ABC-BG1 API using credentials of ABC. - ABC - ABC-BG1 - ABC-BG2 ## Reviewing Unclassified APIs and Permissions concepts If you upgraded APIs from the earlier versions of API Manager to API Manager 2.x, you might have APIs residing in the Unclassified environment. Other APIs that you haven’t associated with an environment, such as an API you create in Design Center, published to Exchange, and set up to manage from Exchange also appear unclassified in API Manager. You need to classify an API to manage it. Until you classify the API, the user permissions under the earlier release apply to all operations. After classification, the permissions per environment that you grant to users applies. ## See Also - [Environments](https://docs.mulesoft.com/access-management/environments) - [Classifying an API instance into an Environment on API Manager](https://docs.mulesoft.com/api-manager/latest/classify-api-task) - [Granting Permission to Access an environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) - [Reviewing API Gateway API Autodiscovery concepts](https://docs.mulesoft.com/mule-gateway/mule-gateway-autodiscovery-overview) - [Configuring Mule Gateway API Autodiscovery in a Mule 4 Application](https://docs.mulesoft.com/mule-gateway/mule-gateway-config-autodiscovery-mule4) --- product: API Manager version: 2.x is-latest-version: true keywords: analytics, dashboard --- # Reviewing Mule API Analytics Usage > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can view your Mule API Analytics data from both API Manager and Anypoint Monitoring. API Manager retains the Mule API Analytics data for up to 30 days. However, Anypoint Monitoring provides more robust API usage data with a retention period of 30 days. To view Mule API Analytics Data in API Manager: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. Click **Mule API Analytics**. From the dashboard, you can navigate to the analytics about your APIs gathered by Anypoint Platform. For more information about how you can view your data in Anypoint Monitoring, see [Monitoring Metrics from Anypoint Insights](https://docs.mulesoft.com/monitoring/anypoint-insights). When you access the analytics for your Mule APIs, by default you land on your Overview Dashboard that displays these charts: - **Requests by Date**: Line chart that shows the number of requests for all APIs in your organization. - **Requests by Location**: Map chart that shows the number of requests for each country of origin. - **Requests by Application**: Bar chart that shows the number of requests from each of the top five registered applications. - **Requests by Platform**: Ring chart that shows the number of requests broken down by platform. ![The API Manager Analytics dashboard.](/mulesoft/current/en-us/api-manager/latest/_images/overviewdash1.png) By default, these charts display the data for APIs in your organization for the past day. You can use the filters at the top left of the page to change the date range or filter to particular APIs. The time ranges reflect your local time zone. ![The Date Range filter drop-down menu showing available date range selections.](/mulesoft/current/en-us/api-manager/latest/_images/filters.png) When selecting a custom time interval, the numbers of request of your requests by day line chart are not normalized. For example, monthly chart will show number of requests per 4 hours. For two months, the same chart shows requests per 8 hours. If you are using a line chart in a custom dashboard and need to define a custom interval, you need to explicitly set an aggregation interval. All of the charts on the Overview Dashboard are cross-filtered. If you filter the data on any one of these charts, the same filter is applied to the other charts on the page. Clicking an individual application in the bar chart, for example, displays all of the requests from that application and the locations for those requests on the map. Here’s how to filter data on individual charts.
ChartHow to filter dataHow to clear your filter

Requests by Date

Click and drag an area of the chart to filter to just that time period. Once you have the slider filter applied, you can drag the ends to adjust them as needed.

Click outside the area of the filtered portion.

Requests by Location

Click one or more countries to filter to just those results. Hover over a country for a tooltip displaying the name of the country and the total number of API requests received from that country for the selected time period.

Click the country or countries again to reset the map.

Requests by Application

Click one or more application bars to filter to just those results. Hover over an application’s data bar for a tooltip displaying the name of the application and the total number of requests from that application for that time period.

Click the application(s) again to reset the chart.

Requests by Platform

Click one or more segments to filter to just those results. Hover over a segment for a tooltip displaying the name of the application and the total number of requests from that application for that time period.

Click the segment(s) again to reset the chart.

To export the data for any of these charts, click the Export icon (![Curved arrow](/mulesoft/current/en-us/api-manager/latest/_images/export.png)). If you have filtered data on one of the charts to show only selected data, the export icon triggers an export of a .csv file of the full data for that chart, filtered by whatever date range and API selection you have made using the filters in the upper left of the page. Exported files are limited to a maximum of 1 million records. ## Including Policy Violations on the Dashboard **Note:** Users must have the `View Policies` permission set to view policies or edit a Policy Violation alert. For more information, see [Setting permissions](https://docs.mulesoft.com/api-manager/latest/environment-permission-task). Enable or disable the tracking of policy violations by checking the Include Policy Violations checkbox on the dashboard. The dashboard will show traffic rejected, or not rejected, by a policy. ![The API Manager policy violations chart with the Include Policy Violations checkbox selected.](/mulesoft/current/en-us/api-manager/latest/_images/policy-violations-chart.png) ## Creating Custom Charts You can create a wide variety of custom charts to display specific data on your custom dashboard. For example, you can create custom charts that show: - Hourly transactions per second between first day of the month and today, filtered by client ID, API version, or SLA tier. - Per minute latency average in the last 24 hours, filtered by API or grouped by client geolocation. - Number of policy violations grouped per subscribed application, per violated policy name Only charts that group by Violated Policy Name include events that triggered a policy violation. All other charts exclude these events. For example, an API gets 100 requests, 90 succeed, and 10 are rejected by the rate-limiting policy. Charts that do not group by Violated Policy Name compute aggregates based on only the 90 requests that were not rate limited. Charts that group by Violated Policy Name, however, include all 100 requests in their computations. To create a custom chart, click Manage Charts: 1. Navigate to **API Manager** > **Mule API Analytics** > **Manage Charts** and click **New**. Create Chart appears. ![The create chart page.](/mulesoft/current/en-us/api-manager/latest/_images/createchart.png) 2. Fill in a **Title**, and, optionally, a **Description**. 3. Click a chart type graphic:
IconChart TypeChart Options

Thumbnail graphic of a line chart.

Line chart

Data Source, Metric: metrics and Total, Data Interval: durations

Thumbnail graphic of a bar chart.

Bar chart

Data Source, Metric: metrics and Total, Group By: categories

Thumbnail graphic of a stack chart.

Stack chart

Data Source, Metric: metrics and Total, Group By: categories, Then By: categories

Thumbnail graphic of a ring chart.

Ring chart

Data Source, Metric: metrics and Total, Group By: categories

Thumbnail graphic of a map chart.

Map chart

Data Source, Metric: metrics and Total

4. Select a Data Source value: - All APIs in your organization - A specific API 5. Select from one of the Metrics _metrics_ value and a Total: - Request Size (in bytes) - Requests - Response Size (in bytes) - Response Time (in milliseconds) 6. For a Line Chart, select a Data Interval _durations_ value: - Minutes - Hours - Days 7. For a Bar Chart or Stack Chart, select a category for Group By, and if your chart supports it, a category for Then By: - API Name - API Version - Application - Browser - City - Client IP - Continent - Country - Hardware Platform - OS Family - OS Major Version - OS Minor Version - OS Version - Postal Code - Resource Path - Status Code - Timezone - User Agent Type - User Agent Version - Verb - Violated Policy Name For Stack chart, you can group your data in two different dimensions. The first defines the distinct columns, the second defines the stacks within these columns. The same options are available on the second grouping dimension as on the first. 8. Save the chart. The custom chart appears. ### Example Custom Chart: Policy Violations Per Application 1. Navigate to **API Manager** > **Mule API Analytics** > **Manage Charts** and click **New**. 2. In Title, type **Policy Violations Per Application**. 3. In Description, type **Number of violations per subscribed application** 4. Select a stack chart. 5. In Data Source and Metric, accept the default values. 6. Select two levels of grouping for the stack chart: - Select Application to display each application in a different column. - Select Violated Policy Name as the stack within each column. ![The bottom part of the create chart page showing Application selected for Group By and Violated Policy Name selected for Then By.](/mulesoft/current/en-us/api-manager/latest/_images/create-chart-2.png) 7. Save the chart. The chart appears: ![A chart that shows policy violations grouped by application.](/mulesoft/current/en-us/api-manager/latest/_images/analytics-violated-policies-2.png) ## Creating a Custom Dashboard After you create custom charts, you can display them side by side on a custom dashboard that is unique to you. To access your custom dashboard, click the Custom Dashboard. The first time you open your custom dashboard, it is blank. 1. Navigate to **API Manager** > **Mule API Analytics** > **Custom Dashboard** and click **Edit Dashboard**. 2. Assuming you created custom charts, drag and drop charts from the drawer on the left of the screen onto your dashboard, rearranging them as needed into the order that you want. 3. After you add a chart to your dashboard, you have the option to open it for editing or click the X to remove it from your dashboard. 4. When you are satisfied with your custom dashboard, save it. The custom dashboard appears. ![A custom dashboard with several custom charts.](/mulesoft/current/en-us/api-manager/latest/_images/custom-dashboard.png) Use the date range picker to adjust the time period for all the charts on your dashboard. ## Exporting Analytics Data You can export your analytics data from the charts displayed on your Overview Dashboard or your Custom Dashboard. On either dashboard, click the Export icon (![Curved arrow](/mulesoft/current/en-us/api-manager/latest/_images/export.png)) to download a CSV file with the data for that chart. The data you download reflects filtering options you selected. However, if you are exporting chart data from the Overview Dashboard and you have selected one or more subsections of a chart, the exported files do not include filtering options. Exported files contain the full data for that chart. ## See Also - [Generate Mule API Analytics Reports with the Event API](https://docs.mulesoft.com/api-manager/latest/analytics-event-api) --- product: API Manager version: 2.x is-latest-version: true keywords: sla, policy, deprecate, delete, define, edit, instance --- # Reviewing SLA Tiers Concepts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt A Service Level Access (SLA) tier is a category of user access that you define for an instance. The tier definition combined with an SLA-based policy determines whether access at a certain level requires your approval. The tier definition also can limit the number of requests an application can make to the instance. To enforce SLA tiers, you need to apply a rate-limiting or throttling policy that is SLA-based. To define SLA tiers for a version of an instance (for example, an API) or to manage applications that request access to specific tiers, you need to set the instance URL. You can monitor SLA performance to ensure that your instances are performing in line with the SLA tier approved for them. ## Defining a Tier When you define a tier, you name the tier and define limits, such as the number of requests calling apps can make. You also indicate whether application access requests at this tier level should be automatically approved or require manual approval. On the SLA Tiers section of the instance details page, a summary of the SLA tier definition appears showing how many applications are registered on that tier and other information, such as tier name, limits, status, and required approval type. You can edit and delete the tier using the provided controls. ### Layered SLAs API Manager supports multiple SLA limits. You can set multiple throughput limits for a single SLA tier. For example, a single SLA tier named _gold_ can limit requests to 100 per second as well as limiting requests to 10,000 per day. This technique ensures that applications registered on a _gold_ tier don’t exceed a bursting limit of 100 requests per second. Applications do not overwhelm the instance, and registered applications get the expected 10,000 requests per day. Setting the Visible flag on an SLA hides the first limit from application developers at registration time. If you define only one limit, you cannot hide it. #### Response Headers Three headers are included in request responses that inform users about the SLA restrictions and the remaining spare capacity that the SLA allows. When multiple SLA-based policies are in place, the headers report spare capacity for only the most restrictive policy. For example, a user may receive a response that includes these headers: X-RateLimit-Limit: 20 X-RateLimit-Remaining: 14 X-RateLimit-Reset: 19100 In this case, the response tells users that within the next 19100 milliseconds, only 14 more requests are allowed by the SLA, which is set to allow 20 within this time window. ## Enforcing a Tier To enforce SLA tiers, you need to apply a rate-limiting or throttling policy that is SLA-based. These policies require all applications that consume the instance to register for access to a specific tier, then pass their client credentials in calls, so that Anypoint Platform can identify them, associate them with their contracted tier, and enforce the throughput limitation. ## Editing a Tier If you edit a tier that already has applications approved to use it, those applications are immediately held to the terms of the edited tier. Thus, if you change the throughput values without warning, you might inconvenience users. If you originally set the tier to require manual approval, and change it to allow automatic approvals, API Manager grants any pending approval requests. ## Managing Applications After you define an SLA for an instance, you can approve or revoke access requests from app developers through the Exchange Portal. This action binds consumption of the application to an SLA. If a developer requests access at a higher SLA tier than you want to approve, you can override the request by applying another SLA tier. If you set the tiers for manual approval, email notifications are sent when developers request access for their applications. You can review the applications on the instance details page and approve, reject, or revoke requests. If a developer asks to change tiers, you can also review the change request and approve the application for the new tier or reject the change request. ## Deprecate a Tier After you assign applications to SLA tiers, you have the option to deprecate a tier to prevent developers from signing up new applications for that tier. You cannot delete an SLA tier that has applications assigned to it. To deprecate a tier: 1. Create a new tier and notify application owners of the new tier name. 2. Revoke application access to the existing, deprecated tier. 3. Ask the application owners to re-request access using the new tier. ## Delete a Tier After all application owners sign up for a new tier and you approve their move to the new tier, you can delete the deprecated tier. To delete a tier: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In the menu, select **API Instances** or **Agent & Tool Instances** 3. Click on an instance name. 4. On the instance dashboard, select **SLA Tiers** from the menu. 5. For the tier to delete, select **Delete** from the **More actions** menu. ## See Also - [About Sharing Assets](https://docs.mulesoft.com/exchange/about-sharing-assets) - [Request Access](https://docs.mulesoft.com/exchange/to-request-access) - [Exchange portals](https://docs.mulesoft.com/exchange/about-portals) - [Reviewing Rate-Limiting SLA Policy](https://docs.mulesoft.com/gateway/latest/policies-included-rate-limiting-sla) - [Approve or Reject Access Requests](https://docs.mulesoft.com/api-manager/latest/manage-client-apps-latest-task) --- product: API Manager version: 2.x is-latest-version: true --- # Revoke and Delete API Contracts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt As the Organization Administrator of the root organization, you can revoke or delete a contract that is providing an application access to your API. When you revoke a contract, you can restore the contract at any time. Deleting a contract deletes the approved contract from Anypoint Exchange. Revoking a contract blocks the client application from accessing the API. When you revoke a contract, you can either restore or delete the contract anytime. Before you delete a contract, you must first revoke it. To delete a contract with an application: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance for which you want to revoke access. 3. Click the `:` link, for example, `v1:16046365`. 4. Click **Contracts**. 5. For the application for which you want to revoke access, click **Revoke**. The **Restore** and **Delete** options appear. 6. To delete the contract, click **Delete**. ## See Also - [Requesting Access to API Instances from Exchange](https://docs.mulesoft.com/exchange/to-request-access) - [Removing API Instance Contracts](#) - [Obtaining Client ID and Client Secret Credentials of a Client Application](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task) --- product: API Manager version: 2.x is-latest-version: true keywords: api, sla, contract --- # SLA Tiers > For the full documentation index, see: https://docs.mulesoft.com/llms.txt - [Reviewing SLA Tiers concepts on API Manager](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers) - [Removing SLA Tiers on API Manager](https://docs.mulesoft.com/api-manager/latest/defining-sla-tiers) - [Open APIs in Private Asset Portals and Public Portals](https://docs.mulesoft.com/api-manager/latest/access-developer-portal-task) --- product: API Manager version: 2.x is-latest-version: true --- # SLA Tiers For API Groups > For the full documentation index, see: https://docs.mulesoft.com/llms.txt As a Group Administrator, you can specify service-level agreement (SLA) tiers for API Groups instances to limit the number of requests an application (user) can make to the APIs in an API Group. SLAs enable you to protect your API Group instances and help manage network traffic to your APIs. The SLA tier definition also determines whether access to the API Groups instance requires your approval. You can configure manual or automatic approvals to requests. ## SLA Types SLA tiers are of two types: - [Default SLAs](#default_SLAs) - [Individual SLAs](#individual_SLAs) ## Default SLAs The default limit applies to all API instances. This means that the same SLA limit is applicable to every API instance in that API Group. If you add a new API instance to an API Group instance, the default limit SLA configured at the group instance level applies, unless an individual API SLA tier is also configured by the Group Administrator. ## Individual SLAs As a Group Administrator, you can define individual limits for API instances within an API Group instance. If you have configured a default SLA limit at the API Group instance level and an individual SLA limit at the API instance level, the individual SLA overrides the default limit. If no individual SLA is configured, then the default SLA limit is enforced for that API instance. If the Rate Limiting policy is applied on an API instance, as a Group Administrator you must determine if the new SLA can be fulfilled by the underlying API instance. ## Manual and Automatic Approvals When you configure automatic approvals for an SLA tier, requests made to the API instances with that tier applied are automatically approved. Consumers can instantaneously use API Group instances in this case. Manual approvals are routed through a manual approval flow, where the API Group owner must manually approve the consumer request. ## Layered SLAs API Groups supports multiple SLA limits. You can set multiple throughput limits for a single SLA tier. A single SLA tier named `Premium` can limit requests to 100 per second as well as limiting requests to 10,000 per day. This strategy ensures that applications registered on a `Premium` tier do not exceed the top limit of 100 requests per second. This way, applications do not inundate the API, and registered applications get the expected 10,000 requests per day. ## See Also - [API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-landing-page) - [Add SLA Tiers to API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-add-sla-tiers) - [Remove SLA Tiers from API Groups](https://docs.mulesoft.com/api-manager/latest/api-groups-remove-sla-tier) - [Manage Group Instance Contracts](https://docs.mulesoft.com/api-manager/latest/api-groups-manage-api-group-instance-contracts) --- product: API Manager version: 2.x is-latest-version: true --- # Switching Environments > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This procedure describes how to switch an API from one environment to another and assumes you have added multiple environments to your organization. If you added no environments, none are listed when you attempt to switch. Exception: The Unclassified environment might appear. If you have upgraded APIs from the earlier versions of API Manager, you might have APIs residing in the Unclassified environment. You need to classify these APIs. See link below. > [!NOTE] API Manager does not support switching to the Design environment. This procedure assumes you added multiple environments in **Access Management** > **Environments** > **Add Environment**. 1. In API Manager, click the environment control. In the following example, this control is labeled SANDBOX: ![API Manager API Administration with the environment sandbox selected.](/mulesoft/current/en-us/api-manager/latest/_images/environment3.png) 2. In Switch Environment, select one of the other listed environments from among the available environments. 3. Click **Switch**. ## See Also - [Environments](https://docs.mulesoft.com/access-management/environments) - [Classifying an API instance into an Environment on API Manager](https://docs.mulesoft.com/api-manager/latest/classify-api-task) --- product: API Manager version: 2.x is-latest-version: true --- # Testing an API Alert > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This procedure describes how to test a request count alert. This procedure requires the following preparation: 1. Design an API. 2. Publish the API to Exchange. 3. In API Manager, manage the API from Exchange. 4. Deploy a proxy of the API instance to CloudHub. 5. Apply the Rate Limiting Policy to the API as follows: Request Count greater than 1 for at least 1 consecutive minute. 6. Add the alert described in the topic about how to add an alert. 7. Call the API. 8. Recall the API two more times (reload the page). Check that `API calls exceeded` appears if you called and recalled the API within the 1 minute period. Any additional page reload operations within the 1 minute period have no effect. 9. Check that users, who you selected for email notification when you added the alert, actually receive email notifications. 10. Check that the alert was resolved. ## See Also - [Add Instance Alerts in API Manager (Mule Gateway)](https://docs.mulesoft.com/api-manager/latest/add-api-alert-task) - [Create and Publish an API Specification or API Fragment](https://docs.mulesoft.com/design-center/design-create-publish-api-specs) --- product: API Manager version: 2.x is-latest-version: true --- # Traits & policies concepts of RAML/OAS based APIs > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If your API exposes a RAML or OAS definition that users might need to reference, then the API definition should reliably detail every element that is expected in calls to your API. For example when applying a client ID-based policies implies that all requests coming to your API include a client ID and client Secret (by default expected as query parameters). To prevent user requests from being rejected, create a trait in the RAML root and then reference this trait in every operation of your API. The trait might look like this: ```yaml traits: - client-id-required: queryParameters: client_id: type: string client_secret: type: string ``` And then you can apply this trait in each individual operation like this: ```yaml /products: get: is: [client-id-required] description: Gets a list of all the inventory products. ``` ## Getting Policies Specification Snippets 1. Click **Policies** on the API dashboard. In the list of policies, the RAML snippet link contains the RAML trait or OAS components you need to add to the API specification. ![The API Manager Policies page.](/mulesoft/current/en-us/api-manager/latest/_images/raml-snippet.png) 2. Click **API Specification Snippet**. 3. Select the API type to match your specification: - RAML 0.8 or RAML 1.0 to match the API RAML version. ![The API Specification Snippet page with RAML 0.8 selected.](/mulesoft/current/en-us/api-manager/latest/_images/snippet-rate-limiting.png) - Or OAS 2.0 to match the API OAS version. ![The API Specification Snippet page with OAS 2.0 selected.](/mulesoft/current/en-us/api-manager/latest/_images/prepare-raml-task-2b676.png) OAS Snippets are not displayed for all policy versions. See the table below to see the policies and the versions that display their OAS snippets:
PolicyVersion

Rate limiting - SLA based

since v1.1.2

OAuth 2.0 access token enforcement using Mule OAuth provider

since v1.1.3

OpenAM access token enforcement

since v1.1.3

OpenId Connect access token enforcement

since v1.1.3

PingFederate access token enforcement

since v1.1.3

Client ID enforcement

since v1.1.3

4. Edit the API to add the code. 5. Redeploy the API. ## See Also - [Provided Policies](https://docs.mulesoft.com/gateway-home/) - [Custom Policies](https://docs.mulesoft.com/gateway/latest/policies-custom-overview) --- product: API Manager version: 2.x is-latest-version: true keywords: api, instance, manager --- # Troubleshooting > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When you perform API Manager tasks, you might encounter issues or receive error messages. The following topics are covered in this section: - [Deployment error when creating policies](https://docs.mulesoft.com/api-manager/latest/troubleshooting-archetype-error-when-creating-policy) - [Deployment error when configuring Autodiscovery](https://docs.mulesoft.com/api-manager/latest/troubleshooting-config-properties-apiid-error) ## See Also - [Known Issues](https://help.salesforce.com/s/issues) --- product: API Manager version: 2.x is-latest-version: true --- # Verify an Agent Using Godaddy Ans > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Verify an agent to establish a trusted identity based on domain ownership and enable its verified status in Anypoint Exchange. Verification uses GoDaddy Agent Name Service (ANS) to validate the domain associated with the agent and confirm that you control it. ## Before You Begin Before verifying an agent, make sure that: - The agent instance is created and deployed in API Manager - A valid consumer endpoint is configured for the agent - You have GoDaddy API credentials (API key and secret) - You have access to manage DNS records for the domain - You have access to a secret group in Secrets Manager For infrastructure requirements such as domain configuration and TLS setup, see [Prepare your environment for agent verification](https://docs.mulesoft.com/api-manager/latest/godaddy-set-up). ## Start Agent Verification 1. In Anypoint Platform, go to **API Manager**. 2. Select the API instance that represents your agent. 3. Click **Actions** > **Verify agent identity**. The verification wizard opens and guides you through the required steps. ## Step 1: Provide Prerequisites In this step: - Confirm or update the **Consumer endpoint** The consumer endpoint is used to derive the domain that is verified. Only the hostname is used. This domain becomes part of the agent’s identity and can’t be changed after registration. - Select a **Secret group** The secret group is used to store credentials and generated security artifacts required for verification. You must have access to at least one secret group with sufficient permissions to continue. If the domain or environment isn’t correctly configured, validation errors are displayed and you can’t proceed. ## Step 2: Enter GoDaddy ANS Credentials Provide your GoDaddy credentials: - **API key** - **API secret** These credentials are used to authenticate with GoDaddy ANS and initiate the verification process. If you don’t already have these credentials, generate them in your GoDaddy account. ## Step 3: Verify Domain Ownership (Acme) To prove domain ownership, create a DNS TXT record using the provided values. 1. Copy the record details. 2. In your DNS provider, create the TXT record. 3. Return to API Manager and click **Verify**. API Manager checks whether the record has been propagated and validated. > [!NOTE] ACME records expire after a limited time. If they expire, new records are generated > automatically when you retry verification. ## Step 4: Verify DNS Records After ACME verification, additional DNS records are generated. 1. Copy the provided DNS records. 2. Add them to your DNS provider. 3. Click **Verify**. These records enable secure communication and complete the verification process. ## Verification Process Verification is asynchronous and depends on DNS propagation and external validation. - Status updates are displayed in API Manager - Verification can take several minutes or longer depending on DNS updates - API Manager continues checking the status after verification is initiated You can close the verification dialog and return later. The status continues to update in the background. ## Retry or Restart Verification If verification isn’t completed: - DNS records can expire after a limited time - You can restart the verification process from the agent instance - New DNS records are generated when restarting ## After Verification When verification is successful: - The agent is marked as verified in API Manager - A verified indicator appears in Anypoint Exchange - The agent is associated with a trusted domain identity --- product: API Manager version: 2.x is-latest-version: true keywords: view contracts, api, contracts, viewing --- # View API Instance Contracts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt From API Manager, you can view the contracts created for your API instance when you grant access to that instance. To view your API instance contracts: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the name of the API instance you want to configure. 3. Click **Contracts**. A tab displays the contract information for your API instance. ## See Also - [Requesting Access to API Instances from Exchange](https://docs.mulesoft.com/exchange/to-request-access) - [Removing API Instance Contracts](https://docs.mulesoft.com/api-manager/latest/remove-client-app-latest-task) - [Obtaining Client ID and Client Secret Credentials of a Client Application](https://docs.mulesoft.com/api-manager/latest/access-client-app-id-task) --- product: API Manager version: 2.x is-latest-version: true --- # View Client Applications with Anypoint DataGraph Contracts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt You can revoke a client application’s access to Anypoint DataGraph, delete the application, or remove the application owner. To view or manage client applications with Anypoint DataGraph contracts, click **Client Applications** from the sidebar in **API Manager**: ![The illustration shows the Client Applications page](/mulesoft/current/en-us/api-manager/latest/_images/datagraph-view-contracts.png)
1Filter applications based on contract types. Select Clients with DataGraph Contracts to view only applications with DataGraph contracts.
2Choose a client applications to see its contract details.
3View the contract options for a selected client application.

From this view, you can reset a client secret, revoke a client contract, delete an application, or remove the application owner.

## See Also - [Anypoint DataGraph Overview](https://docs.mulesoft.com/datagraph/) - [Anypoint DataGraph Supported Authentication Methods](https://docs.mulesoft.com/datagraph/security) --- product: API Manager version: 2.x is-latest-version: true --- # View Mule API Analytics Charts in API Manager > For the full documentation index, see: https://docs.mulesoft.com/llms.txt Mule API Analytics charts in API Manager summarize requests, top client applications, and average latency for a deployed API instance across one hour, three hours, one day, seven days, or one month, with a 30-day retention window. In API Manager, click the instance name to open the charts when your user has `View APIs Configuration` permission; see [Grant Permission to Access an Environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) for access setup. You can include policy violation traffic on the same charts when you have `View Policies` permission. ## Requests Summary Chart The requests summary chart lists the total number of requests to your API instance by the duration you choose. The chart shows the HTTP status codes specified by W3C. For example: ![Summary chart of the total number of requests for June 1, 2017, shown by one hour duration.](/mulesoft/current/en-us/api-manager/latest/_images/request-analytics.png) Graph lines are provided for: - Green - Successful requests that returned a status code from 1xx to 3xx. - Dark Gray - Client failed requests that returned a status code of 4xx. - Blue - Server failed requests that returned a status code of 5xx. ## Top Apps Summary Chart The top apps summary chart lists the number of requests made to the API instance by each application for the top 5 applications calling that API instance. Each color represents one of the top 5 applications accessing the API. The y-axis plots the number of calls made to the API instance. The graph lists the number of requests over the duration you select, for example: ![Summary chart of requests for the top five applications for June 1, 2017, shown by one hour duration.](/mulesoft/current/en-us/api-manager/latest/_images/top-apps-analytics.png) ## Latency Summary Chart The latency summary chart lists the average API latency for the period selected. The higher the latency, the lower the performance. The y-axis in the chart lists the average latency in milliseconds (ms). For example, the chart can show that the worst average performance in the one-hour period was at 8:30 am. ![A latency summary chart showing the average latency for the highest point on the chart, which is 8:30 am.](/mulesoft/current/en-us/api-manager/latest/_images/performance-analytics.png) ## Policy Violations on Charts > [!NOTE] Users must have the `View Policies` permission set to view policies or edit a Policy > Violation alert. Enable or disable the tracking of policy violations by checking the Include Policy Violations checkbox on a Mule API Analytics chart screen. The chart shows traffic rejected, or not rejected, by a policy. ![An analytics chart screen with the Include Policy Violations checkbox indicated with a callout.](/mulesoft/current/en-us/api-manager/latest/_images/policy-violations-dashboard.png) ## See Also - [Grant Permission to Access an Environment](https://docs.mulesoft.com/api-manager/latest/environment-permission-task) --- product: API Manager version: 2.x is-latest-version: true --- # Viewing and Deleting API Alerts > For the full documentation index, see: https://docs.mulesoft.com/llms.txt If you have been granted the **Organization Administrators** role for the root organization, you can view a list of alerts that are generated for APIs in the API Manager. Before you can view and delete alerts, ensure that you have: - **Manage Alerts** permission to view and delete API alerts. - **View Alerts** permission to only view alerts. For more information about how to set these permissions, see [To Set Permissions](https://docs.mulesoft.com/api-manager/latest/environment-permission-task). To view and delete alerts: 1. Navigate to **Anypoint Platform** > **API Manager**. 2. In **API Administration**, click the API instance whose alert you want to view or delete. 3. Click **Alerts** 4. Expand the alert you want to delete. Details about the alert options appear. 5. Click **Delete**.