API Manager
API Manager is the MuleSoft Anypoint Platform component that governs APIs at run time.
Definition
API Manager is the MuleSoft Anypoint Platform component that governs APIs at run time. It applies policies such as rate limiting, client ID enforcement, and OAuth 2.0 token enforcement through an API proxy. Every consumer call passes through that proxy before it reaches the backend implementation, so the platform team gets one control plane for security, traffic, and access. Where Anypoint Exchange and the API Catalog handle discovery and documentation, API Manager handles enforcement.
In the API-Led Connectivity model, API Manager sits in front of every System, Process, and Experience API. Each API is registered, a policy bundle is applied, and consumer applications request access by signing up for a client ID and secret. That access is recorded as a contract, often tied to an SLA tier. The result is a clear audit trail of which consumers called which APIs, how often, and whether they hit their limits. Without it, run-time governance falls to ad hoc checks inside each implementation.
How API Manager governs traffic before it reaches your backend
The proxy is where enforcement happens
API Manager works through an API proxy, and that proxy is the single most important idea in the product. Instead of exposing the backend service directly, the team sets up a proxy that routes requests to it. A client sends a request to the public endpoint, the request hits the proxy managed in API Manager, the proxy checks it against the active policies, and only then is it forwarded to the backend implementation. Policies are enforced at the proxy well before any traffic reaches your backend service. This design has a quiet but large benefit. You can require credentials, throttle traffic, or block by header or IP without touching backend code at all. You can also swap out or update backend services without changing the public interface that consumers depend on. Monitoring and version control run through the same proxy layer. For a platform team, that separation between the public contract and the private implementation is what makes governance practical at scale, because policy changes never force a redeploy of the underlying Mule application or service.
Policies, the core enforcement primitive
A policy is a reusable rule applied to an API at the proxy. Anypoint API Manager ships a range of policy types so teams can secure and govern traffic without custom code. Client ID Enforcement requires applications to provide a valid client ID and client secret to access the API. OAuth 2.0 Access Token Enforcement validates tokens against an external OAuth 2.0 provider. Rate Limiting restricts how many requests a client can make in a given time frame, for example 1,000 requests per hour. Spike Control focuses on preventing sudden bursts of traffic that could overwhelm backend services. Beyond these, the platform offers header and IP filtering, JSON and XML threat protection, and message transformation policies. An API can carry several policies at once, and they run in sequence as each request passes through. Because policies live on the proxy, you configure and update them in API Manager without redeploying the implementation. The practical skill is choosing the smallest set that meets the security and traffic goals, since every added policy is one more thing to audit and one more step in the request path.
Contracts and consumer applications
A consumer does not get to call a governed API just by knowing its URL. They register an application, then request access to a specific API. That request becomes a contract. On approval, the consumer receives a client ID and client secret to include in their calls, which the Client ID Enforcement policy then checks on every request. The contract is the governance record. It links one named consumer to one API, so the platform team can see exactly who is allowed in and revoke that access cleanly when a partner relationship ends or an internal app is retired. This is very different from sharing a single shared credential across every caller. With contracts, usage is attributable. When traffic spikes or an endpoint misbehaves, you can trace it to the consuming application rather than guessing. Contracts also gate the rate limits a consumer is subject to, because they can be attached to an SLA tier. That pairing of identity and limit is the foundation everything else in API Manager builds on, and it is why approving every contract automatically quietly removes most of the value.
SLA tiers for different consumer classes
An SLA tier bundles a rate limit and an approval behaviour into a named package that the API owner defines. A Basic tier might allow a modest number of calls per hour with automatic approval, while a Premium tier allows far more with manual approval by the API owner. When a consumer requests a contract, they choose a tier, and the matching rate limit is applied to their client ID. Tiers are how one API serves several consumer classes from a single deployment. Internal teams, trusted partners, and public developers can all call the same endpoint at limits that fit their relationship, without the platform team maintaining three near-identical APIs. This keeps the implementation single-sourced and the governance model readable. The alternative, spinning up a separate API per audience, multiplies maintenance and drifts over time as fixes land in one copy but not the others. SLA-based rate limiting also gives the owner a lever during incidents. If a low-priority tier is generating load that threatens a high-priority one, the limits already encode that priority, so the system protects the important consumers by design rather than by manual intervention.
Monitoring, alerts, and governance in production
Once an API is live, the platform team needs to know how it behaves. Anypoint Runtime Manager acts as the control center for deployed Mule applications, where you view performance metrics like response time, throughput, and memory usage and track the number of incoming requests and any errors they generate. The metrics that matter most are response time, error rate, throughput, and latency, the delay between receiving and processing a request. Alerts turn those metrics into action. When a threshold is crossed, the system can send a notification through email or integrate with external notification or incident management systems, so the team hears about a problem before consumers do. Separately, Anypoint API Governance checks the design itself. It lets teams apply rulesets to check for required security schemes, naming patterns, or documentation, and automate compliance checks to reduce manual review. Governance and run-time monitoring answer different questions. One asks whether an API is built to standard, the other asks whether it is healthy right now. Mature platform teams wire up both on day one, so a new API arrives already measured and already checked against the organisation's rules rather than retrofitted later.
Gateways and where API Manager runs
API Manager enforces policies through a gateway that hosts the proxy. The Mule Gateway runs on the same Mule runtime that hosts MuleSoft applications, which suits teams already deploying Mule. Anypoint also offers Flex Gateway, a lightweight gateway built to sit in front of any HTTP service, including endpoints that are not Mule applications at all. That matters for Salesforce shops, because a Flex Gateway can apply the same rate limiting, authentication, and analytics to a partner service or even an Apex REST endpoint that it applies to a native Mule API. The benefit is one consistent governance layer across the whole integration estate rather than separate enforcement per technology. Whichever gateway you choose, the request path is the same: the consumer hits the gateway, the gateway runs the policy bundle, and approved requests pass to the implementation. Choosing the gateway is largely a deployment decision driven by where your services already run and how lightweight you need the footprint to be. For protecting non-Mule workloads, Flex Gateway is usually the answer, and it is what lets a platform team extend API Manager beyond MuleSoft-built APIs.
Versioning, lifecycle, and common pitfalls
API Manager lets multiple versions of an API run in parallel, each with its own policy bundle, so consumers migrate at their own pace instead of all at once. Retiring a version is a lifecycle change rather than a hard delete, which gives consumers warning and a window to move. Three pitfalls show up again and again in real rollouts. Over-policying, applying ten policies where three would do, adds latency to every call and friction for every consumer, and it makes the configuration hard to audit. Auto-approving every contract is the second, because it turns contracts into a formality and erases the attributable-access benefit that justified them. Skipping versioning is the third, because it makes any breaking change a coordinated emergency across every caller at once. Each pitfall comes from treating API Manager as a one-time setup task rather than an ongoing practice. The product rewards teams that keep policy bundles lean, review who is granted access, and plan versions ahead of breaking changes. Done that way, API Manager becomes the dependable front door for an organisation's APIs rather than a box that was ticked during the initial build.
How to set up and govern an API in API Manager
Setting up an API in API Manager means registering it, putting a proxy in front of it, attaching the policies that protect it, and giving consumers a way to request access. These steps assume you have an Anypoint Platform account with API Manager and an environment selected.
- Add the API to API Manager
In API Manager, choose to manage a new API. Point it at the API specification in Exchange or at the endpoint you want to govern, and let API Manager create the managed proxy that consumers will call instead of the backend directly.
- Apply a starting policy bundle
Open the API and add policies. Begin with Client ID Enforcement so callers must present credentials, then add Rate Limiting or an SLA-based limit. Keep the bundle small and note the order, since policies run in sequence on each request.
- Define SLA tiers
Create the tiers consumers can request, for example a Basic tier with auto-approval and a Premium tier with manual approval. Each tier carries its own rate limit, so one API can serve internal, partner, and public callers from a single deployment.
- Approve contracts and monitor
As consumers register applications and request access, review and approve each contract rather than auto-approving. Then watch response time, error rate, and throughput in Runtime Manager and set an alert so threshold breaches reach the team by email.
Requires every caller to send a valid client ID and client secret, tying each request to an approved contract.
Caps requests over a time window, either flat for the API or per SLA tier so different consumer classes get different limits.
Validates incoming tokens against an external OAuth 2.0 provider when you need token-based access rather than client credentials alone.
Smooths sudden bursts of traffic so a momentary flood does not overwhelm the backend service behind the proxy.
- Auto-approving every contract turns contracts into paperwork and removes the attributable-access benefit that justifies them.
- Each policy adds a step to the request path, so an over-stuffed bundle raises latency and is hard to audit later.
- Policies live on the proxy, so a consumer who reaches the backend endpoint directly bypasses them; lock down the implementation so only the gateway can call it.
- Skipping versioning makes any breaking change a coordinated emergency across every consumer at the same time.
Prefer this walkthrough as its own page? How to API Manager in Salesforce, step by step
Trust & references
Cross-checked against the following references.
Straight from the source - Salesforce's reference material on API Manager.
Hands-on resources to go deeper on API Manager.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which platform is the Salesforce API Manager part of?
Q2. Which item is NOT typically configured inside API Manager?
Q3. What is the primary purpose of API Manager?
Discussion
Loading discussion…