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 Anypoint Omni Gateway, Anypoint Mule Gateway, Anypoint Service Mesh, 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: To specify the structure of the API
-
Exchange: To store and publish API and server assets
-
Studio: To implement the API
-
Runtime Manager: To deploy, manage, and monitor API instances
-
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:
To access API Manager, log in to Anypoint Platform and select API Manager:
-
The 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 switch-environment-task.adoc.
-
Sidebar:
-
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-landing-page.adoc.
-
Agent and Tool Instances
The Agent and Tool Instances tab represents server instances that extend Anypoint 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 create-instance-task-agent-tool.adoc.
-
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-contracts.adoc.
-
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 datagraph::index.adoc. 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 viewing-api-analytics.adoc.
-
-
The 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-proxy.adoc.
-
The 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 provision the Anypoint Service Mesh adapter or to configure Studio to sync with your environment.
-
Search. Enables you to search for managed APIs using the API search field. Searches are case-insensitive. Filter search results by selecting Active.
-
The 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. -
The name of each API. Clicking the API name navigates you to the API Settings view, where you manage the following:
-
API Summary
For details, see api-instance-landing-page.adoc.
-
Alerts
For details, see using-api-alerts.adoc.
-
Contracts
For details, see api-contracts-landing-page.adoc.
-
Policies
For details, see policies-landing-page.adoc.
-
SLA Tiers
For details, see defining-sla-tiers.adoc.
-
Settings
For details, see edit-api-endpoint-task.adoc.
-
Governance Report
For details, see govern-api-instances.adoc.
-
-
The 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 monitoring::quick-start.adoc.
-
The 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 monitoring::quick-start.adoc.
-
The number of contracted client applications for each API. For details, see api-contracts-landing-page.adoc.
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. |
An API instance describes a configuration of an API that is deployed on one of the following runtimes: Omni Gateway, Mule Gateway, or Anypoint Service Mesh. 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 api-instance-landing-page.adoc.
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 using-api-alerts.adoc.
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 api-contracts-landing-page.adoc.
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 policies-landing-page.adoc.
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 defining-sla-tiers.adoc.
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.adoc.
After you create the API instance, you can edit the configuration settings from Settings.
To edit an API instance, see edit-api-endpoint-task.adoc.
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 govern-api-instances.adoc.
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-credential-providers.adoc.
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 exchange::about-sharing-assets.adoc.
When you create or edit APIs in API Manager, use apikit::apikit-simulate.adoc 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 manage-exchange-api-task.adoc.
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-landing-page.adoc.
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.
|
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 access-management::business-groups.adoc.
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 access-management::environments.adoc.
-
general::api-led-overview.adoc
-
general::glossary.adoc