A developer is configuring API Auto-Discovery in a Mule 4 application generated by APIkit scaffolding. The application XML contains an HTTP Listener flow named api-main containing the component, and several backend subflows named get:\customers:api-config, post:\customers:api-config, etc. To which flow must the element's flowRef attribute point?

To the main APIkit router flow (api-main) that receives incoming requests from the HTTP Listener.. The flowRef attribute in must point to the main entry flow of the application (typically named api-main or {apiName}-main) where the HTTP Listener and APIkit Router reside. This ensures that the API Gateway intercepts all incoming HTTP requests at the boundary before they are routed by APIkit to backend implementation flows.

12.3 API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

Key Takeaways

API Auto-Discovery (<api-gateway:autodiscovery>) binds a deployed Mule runtime application flow (typically api-main) to an API instance in Anypoint API Manager using the apiId and platform client credentials.
The embedded API Gateway intercepts inbound requests before they reach backend flows, dynamically downloading, applying, and enforcing policies managed in API Manager without requiring application redeployments or code changes.
Out-of-the-box standard API policies span Security (Client ID Enforcement, Basic Authentication, OAuth 2.0 Token Enforcement, IP Blacklist/Whitelist, JWT Validation), Quality of Service (Rate Limiting, SLA-based Rate Limiting, Spike Control), and Compliance (Message Logging, Header Injection/Removal, Threat Protection).
Policy execution order follows strict pointcut precedence (Pre-transformation -> Authentication/Security -> Traffic Control / Rate Limiting -> Implementation Flow -> Post-transformation), which can be customized via Policy Ordering in API Manager.
SLA Tiers define contractual consumption limits (e.g., Free: 100 req/hr, Gold: 10,000 req/hr) requiring client applications to register contracts in Anypoint Exchange, obtain client credentials, and undergo manual or automated approval.

Last updated: August 2026

API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

Designing and implementing robust integration logic is only half of the API lifecycle. In an enterprise application network, APIs must be secured, governed, throttled, and audited. Anypoint API Manager provides centralized governance and policy management, pairing with the Mule runtime's embedded API Gateway to enforce runtime controls dynamically without altering application source code. Understanding API Auto-Discovery, standard out-of-the-box policies, execution precedence, and SLA tiers is critical for the Developer I certification.

1. API Manager Architecture & The Embedded API Gateway

Anypoint Platform decouples policy administration in the Control Plane from policy enforcement in the Runtime Plane.

+-----------------------------------------------------------------------------------------+
|                        API MANAGER & API GATEWAY ARCHITECTURE                           |
|                                                                                         |
|   +---------------------------------------------------------------------------------+   |
|   | ANYPOINT CONTROL PLANE (API Manager)                                            |   |
|   | - Define API Instances, SLA Tiers & Contracts                                   |   |
|   | - Configure Policies (Client ID Enforcement, Rate Limiting, JWT Validation)      |   |
|   +---------------------------------------------------------------------------------+   |
|                            |                                                            |
|                            | (1. Dynamic Policy Sync via HTTPS Polling)                 |
|                            v                                                            |
|   +---------------------------------------------------------------------------------+   |
|   | MULE RUNTIME (Embedded API Gateway)                                             |   |
|   |                                                                                 |   |
|   |  [Inbound Client Request]                                                       |   |
|   |            |                                                                    |   |
|   |            v                                                                    |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |   | EMBEDDED API GATEWAY INTERCEPTOR                                        |   |   |
|   |   | (Enforces Client ID -> IP Filter -> Rate Limiting -> JWT Verification)   |   |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |            | (Passed All Policies)                                              |   |
|   |            v                                                                    |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   |   | MULE APPLICATION FLOW (<flow name="api-main">)                          |   |   |
|   |   | - APIkit Router -> Business Logic Implementation Flows                  |   |   |
|   |   +-------------------------------------------------------------------------+   |   |
|   +---------------------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------------------+

Core Architectural Principles:

Zero Code Modification: Policies (such as Rate Limiting, CORS, or OAuth 2.0 Token Enforcement) are applied, updated, or removed in the API Manager web interface. The embedded API Gateway downloads and enforces them dynamically without requiring developers to redeploy or modify application XML.
Local Policy Caching: The API Gateway polls API Manager periodically for policy changes and caches active policies locally. If connectivity to the Anypoint Control Plane is temporarily lost, the API Gateway continues enforcing cached policies without disrupting runtime traffic.
Request Interception: The API Gateway intercepts incoming HTTP requests at the HTTP Listener layer before the message reaches the APIkit Router or backend business flows.

2. API Auto-Discovery Mechanics & Configuration

API Auto-Discovery is the runtime mechanism that pairs a deployed Mule application with its corresponding managed API instance in API Manager.

+-----------------------------------------------------------------------------------------+
|                             API AUTO-DISCOVERY PAIRING FLOW                             |
|                                                                                         |
|   1. APPLICATION STARTUP                                                                |
|      Mule Runtime reads:                                                                |
|      - anypoint.platform.client_id     = 'prod_client_id_123'                           |
|      - anypoint.platform.client_secret = 'prod_secret_456'                              |
|      - <api-gateway:autodiscovery apiId="18920412" flowRef="api-main" />                |
|                                                                                         |
|   2. CONTROL PLANE HANDSHAKE                                                            |
|      Mule Runtime connects to API Manager using Org Credentials + apiId (18920412)       |
|                                                                                         |
|   3. STATUS TRANSITION IN API MANAGER                                                   |
|      Status changes from: [ Unregistered ]  ===>  [ Active / Tracking ]                 |
|                                                                                         |
|   4. POLICY SYNC & GATEWAY HOOK                                                         |
|      API Gateway injects policy interceptors directly into flow: "api-main"             |
+-----------------------------------------------------------------------------------------+

XML Configuration of Auto-Discovery

In the global configuration XML file of your Mule application, declare the <api-gateway:autodiscovery> element:

<mule xmlns="http://www.mulesoft.org/schema/mule/core"
      xmlns:doc="http://www.mulesoft.org/schema/mule/documentation"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:api-gateway="http://www.mulesoft.org/schema/mule/api-gateway"
      xsi:schemaLocation="
        http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
        http://www.mulesoft.org/schema/mule/api-gateway http://www.mulesoft.org/schema/mule/api-gateway/current/mule-api-gateway.xsd">

    <!-- API Auto-Discovery Global Configuration -->
    <api-gateway:autodiscovery 
        apiId="${api.id}" 
        flowRef="api-main" 
        doc:name="API Autodiscovery" />

</mule>

Mandatory Runtime Platform Properties

For Auto-Discovery to authenticate with API Manager, the Mule runtime must have the following two environment properties configured (in wrapper.conf for standalone runtimes, or in Runtime Manager Properties for CloudHub):

anypoint.platform.client_id: The Client ID of the Anypoint Platform Organization / Business Group.
anypoint.platform.client_secret: The Client Secret of the Organization / Business Group.

[!IMPORTANT] Why flowRef Must Point to api-main In an APIkit-scaffolded application, the flowRef attribute of <api-gateway:autodiscovery> must point to the main entry flow containing the HTTP Listener and APIkit Router (conventionally named api-main or {apiName}-main). If flowRef points to a backend implementation flow (such as get:\customers), policies will only protect that single subflow, leaving other API endpoints exposed and unmonitored.

3. Standard Out-of-the-Box (OOTB) API Policies

API Manager includes a comprehensive suite of pre-built, standard policies organized into three functional categories:

+-----------------------------------------------------------------------------------------+
|                            STANDARD API POLICIES TAXONOMY                               |
|                                                                                         |
|   +--------------------------+  +--------------------------+  +---------------------+   |
|   | 1. SECURITY POLICIES     |  | 2. QUALITY OF SERVICE    |  | 3. COMPLIANCE & DATA|   |
|   | - Client ID Enforcement  |  | - Rate Limiting (General)|  | - Message Logging   |   |
|   | - Basic Authentication   |  | - Rate Limiting (SLA)    |  | - Header Injection  |   |
|   | - OAuth 2.0 Token Enforce|  | - Spike Control          |  | - Header Removal    |   |
|   | - IP Whitelist / Blacklist| |                          |  | - JSON/XML Threat   |   |
|   | - JWT Validation         |  |                          |  | - CORS              |   |
|   +--------------------------+  +--------------------------+  +---------------------+   |
+-----------------------------------------------------------------------------------------+

1. Security Policies

Client ID Enforcement: Mandates that every inbound request supply a valid client_id and client_secret (via HTTP headers or query parameters). The API Gateway validates credentials against approved client application contracts in Anypoint Exchange.
Basic Authentication (Simple / LDAP): Enforces standard HTTP Basic Authentication against hardcoded credentials or an external LDAP/Active Directory identity directory.
OAuth 2.0 Access Token Enforcement: Intercepts incoming Bearer tokens and validates them by making token introspection calls to an external Identity Provider (such as Okta, PingFederate, Salesforce, or OpenID Connect).
JWT Validation: Cryptographically verifies incoming JSON Web Tokens (Authorization: Bearer <JWT>) using RSA or HMAC keys. Validates token claims including issuer (iss), audience (aud), expiration (exp), and custom scopes without making external network calls.
IP Whitelist / Blacklist: Filters incoming traffic based on client IP addresses or CIDR blocks. Evaluates the X-Forwarded-For header when traffic traverses intermediate load balancers.

2. Quality of Service (QoS) & Traffic Management Policies

Rate Limiting (General): Enforces a global quota on the maximum number of requests allowed across a sliding or fixed time window (e.g., maximum 1,000 requests per minute across all consumers). Excess requests are rejected with HTTP 429 Too Many Requests.
Rate Limiting - SLA Based: Enforces tier-specific rate limits based on the client application's approved contract tier (e.g., Bronze Tier allows 100 req/min, Gold Tier allows 10,000 req/min).
Spike Control: Protects backend systems from sudden traffic bursts by smoothing request spikes. Allows administrators to define a maximum request volume per sliding time window and configure whether excess requests are rejected or queued.

3. Compliance & Content Transformation Policies

Message Logging: Logs incoming request attributes, headers, and payloads before and after flow execution for compliance auditing.
Header Injection & Header Removal: Injects custom HTTP headers into requests before forwarding to backend flows (e.g., injecting tracking correlation IDs) or removes sensitive internal headers from outgoing responses.
JSON / XML Threat Protection: Shields applications from Denial of Service (DoS) attacks by validating payload depth, maximum string length, maximum array sizes, and XML entity expansion.
Cross-Origin Resource Sharing (CORS): Manages browser-based cross-origin request headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods).

4. Policy Execution Ordering & Precedence Matrix

When multiple policies are applied to an API, the embedded API Gateway evaluates them across the five-stage request lifecycle below. Policy order is configurable per API in API Manager, so treat this as the default arrangement rather than an immutable rule — what the exam does test is that security policies reject a request before traffic-management policies or the Mule flow ever run:

+-----------------------------------------------------------------------------------------+
|                           POLICY EXECUTION POINTCUT LIFECYCLE                           |
|                                                                                         |
|   [Inbound HTTP Request]                                                                |
|          |                                                                              |
|          v                                                                              |
|   [STAGE 1: PRE-PROCESSING & COMPLIANCE]                                                |
|   - CORS -> JSON/XML Threat Protection -> Header Injection                              |
|          |                                                                              |
|          v                                                                              |
|   [STAGE 2: AUTHENTICATION & SECURITY FILTERS]                                          |
|   - IP Whitelist -> Client ID Enforcement -> Basic Auth -> JWT / OAuth Token Enforcement |
|          |                                                                              |
|          v                                                                              |
|   [STAGE 3: TRAFFIC GOVERNANCE & QUALITY OF SERVICE]                                    |
|   - Spike Control -> Rate Limiting (General) -> Rate Limiting (SLA-Based)               |
|          |                                                                              |
|          v                                                                              |
|   [STAGE 4: MULE IMPLEMENTATION FLOW EXECUTION]                                         |
|   - <flow name="api-main"> (APIkit Router -> Business Logic)                            |
|          |                                                                              |
|          v                                                                              |
|   [STAGE 5: POST-PROCESSING & OUTBOUND MODIFICATIONS]                                   |
|   - Outbound Header Injection -> Message Logging -> Response to Client                  |
+-----------------------------------------------------------------------------------------+

Policy Precedence Matrix Table

Policy Type	Execution Phase	Default Order	Failure Behavior / Status Code
CORS	Pre-processing	Stage 1	Rejects cross-origin preflight (`403 Forbidden`)
JSON/XML Threat Protection	Pre-processing	Stage 1	Rejects malformed/oversized payload (`400 Bad Request`)
IP Whitelist / Blacklist	Security Filter	Stage 2	Rejects unauthorized client IP (`403 Forbidden`)
Client ID Enforcement	Security Filter	Stage 2	Rejects missing/invalid credentials (`401 Unauthorized`)
OAuth 2.0 / JWT Validation	Security Filter	Stage 2	Rejects invalid signature or expired token (`401 Unauthorized`)
Spike Control	Traffic Governance	Stage 3	Rejects or queues burst requests (`429 Too Many Requests`)
Rate Limiting (SLA-Based)	Traffic Governance	Stage 3	Rejects requests exceeding tier quota (`429 Too Many Requests`)
Message Logging	Post-processing	Stage 5	Writes audit telemetry to console logs

Short-Circuiting Mechanics

If a request fails validation at any stage (e.g., Client ID Enforcement fails due to invalid credentials in Stage 2), the API Gateway immediately short-circuits execution. It returns an HTTP 401 Unauthorized response to the client and never evaluates subsequent policies (such as Rate Limiting) or routes the message to the Mule flow.

5. SLA Tiers, Client Applications & Exchange Contract Workflows

To monetize APIs or enforce differentiated service levels for distinct consumers, API Manager enables Service Level Agreement (SLA) Tiers.

+-----------------------------------------------------------------------------------------+
|                        SLA TIER CONTRACT & CONSUMPTION WORKFLOW                         |
|                                                                                         |
|   1. API OWNER (API Manager):                                                           |
|      - Defines SLA Tiers:                                                               |
|        * Bronze Tier: 100 requests / hour (Auto-Approve)                                |
|        * Silver Tier: 1,000 requests / hour (Manual Approval Required)                  |
|        * Gold Tier:   10,000 requests / hour (Manual Approval Required)                |
|      - Applies "Rate Limiting - SLA Based" Policy to API Instance                       |
|                                                                                         |
|   2. API CONSUMER (Anypoint Exchange):                                                  |
|      - Discovers API in Exchange -> Clicks "Request Access"                             |
|      - Registers new "Client Application" (or selects existing)                         |
|      - Selects desired SLA Tier (e.g., Silver Tier)                                     |
|                                                                                         |
|   3. CONTRACT APPROVAL & CREDENTIAL ISSUANCE:                                           |
|      - Automated or Manual approval granted by API Owner                                |
|      - Exchange issues unique client_id and client_secret to Consumer                   |
|                                                                                         |
|   4. RUNTIME ENFORCEMENT (API Gateway):                                                 |
|      - Client sends: client_id & client_secret in HTTP headers                          |
|      - Gateway verifies Silver Tier contract and tracks quota (1,000 req/hr)            |
+-----------------------------------------------------------------------------------------+

The 4 Steps of SLA Tier Management:

Define Tiers in API Manager: Configure rate limits, time intervals, and approval type (Automatic vs. Manual approval).
Apply SLA-Based Rate Limiting Policy: Select the Rate Limiting - SLA Based policy on the target API instance in API Manager.
Request Access in Exchange: The consumer developer navigates to the published API in Anypoint Exchange, clicks Request Access, registers a client application, and chooses an SLA tier.
Runtime Enforcement: Once the contract is approved, the client application passes its issued client_id and client_secret in request headers. The embedded API Gateway dynamically verifies the active contract and enforces the corresponding SLA rate quota.

6. Managing APIs With a Separate Proxy Instead of Auto-Discovery

Auto-discovery is only one of the two ways API Manager can put a governed API instance in front of a backend. The other is a separate API proxy: API Manager generates a lightweight Mule proxy application, you deploy it to CloudHub, Anypoint Runtime Fabric, a hybrid server, or a standalone runtime, and it forwards traffic to the backend implementation URL while enforcing every policy attached to that API instance.

+---------------------------------------------------------------------------------------------------+
|                  ENDPOINT WITH NO PROXY (AUTO-DISCOVERY)  vs.  ENDPOINT WITH PROXY                |
|                                                                                                   |
|  A. AUTO-DISCOVERY (in-process)              B. SEPARATE PROXY (extra hop)                        |
|                                                                                                   |
|  [Client]                                    [Client]                                             |
|     |                                           |                                                 |
|     v                                           v                                                 |
|  +---------------------------------+       +----------------------------+                        |
|  | MULE APP                        |       | PROXY APP (generated Mule) |                        |
|  |  Gateway interceptor + policies |       |  Gateway + policies        |                        |
|  |  -> api-main -> business flows  |       +----------------------------+                        |
|  +---------------------------------+                    |                                        |
|     (one deployable, no extra hop)                       v (HTTP forward)                        |
|                                              +----------------------------+                      |
|                                              | BACKEND (Mule OR non-Mule) |                      |
|                                              +----------------------------+                      |
+---------------------------------------------------------------------------------------------------+

Choosing Between Them

Situation	Correct option
The API implementation is your own Mule 4 application and you can edit its XML	Auto-discovery — one deployable, no extra network hop
The backend is a non-Mule service (Java, .NET, Node, a SaaS endpoint)	Separate proxy — the proxy is agnostic to the backend location and programming language
You have an existing Mule application whose source you cannot modify	Separate proxy — auto-discovery requires adding configuration inside the application
The API is not hosted on a Mule runtime at all yet	Separate proxy — it can front the API immediately without Mule development
Latency budget is tight and every millisecond counts	Auto-discovery — a proxy introduces an additional hop between client and backend

[!IMPORTANT] One Blueprint Objective, Two Mechanisms The exam objective is manage APIs using separate proxies and auto-discovery, and both mechanisms enforce the same API Manager policies and produce the same analytics. The difference is only where enforcement runs: auto-discovery embeds the API Gateway inside the implementation application, while a proxy runs the gateway in its own deployed application in front of the backend. When a scenario states that the backend cannot be modified, has closed source, or is not a Mule application, auto-discovery is unavailable and the separate proxy is the answer.

7. Exam Watch: Core API Manager & Gateway Scenarios

[!IMPORTANT] Auto-Discovery Flow Reference The <api-gateway:autodiscovery> element's flowRef attribute must always reference the flow that contains the APIkit Router (flowRef="api-main"). Pointing to a backend subflow or error handler is a major exam distractor.

[!WARNING] Missing Organization Credentials If a Mule application is deployed with <api-gateway:autodiscovery> but the runtime environment lacks anypoint.platform.client_id and anypoint.platform.client_secret, the application will start, but the API status in API Manager will remain Unregistered, and zero policies will be enforced.

[!TIP] Rate Limiting vs. Rate Limiting - SLA Based

Rate Limiting: Enforces a single global quota across all incoming traffic regardless of consumer identity.

Rate Limiting - SLA Based: Enforces individual rate quotas specific to each consumer application's approved SLA tier contract.

Test Your Knowledge

A developer deploys a Mule application implementing a REST API to CloudHub 1.0 and configures API Auto-Discovery in the Mule XML configuration. However, in Anypoint API Manager, the API status remains 'Unregistered' and none of the configured security policies are enforced. What is the most likely cause of this issue?

The application's pom.xml file is missing the munit-runner dependency required for API Gateway policy synchronization.

The API specification in Anypoint Design Center has not been converted from RAML 1.0 to OAS 3.0.

The CloudHub Dedicated Load Balancer has blocked inbound communication on port 8081.

The Mule runtime environment was not configured with the organization's anypoint.platform.client_id and anypoint.platform.client_secret runtime properties.

Test Your Knowledge

An organization wants to secure an Experience API by requiring all client applications to identify themselves. Furthermore, different consumer applications must be granted different rate limits (such as Bronze: 50 requests/min, Silver: 500 requests/min, Gold: 5,000 requests/min). Which combination of API Manager features should be configured?

Apply a Spike Control policy and configure IP Whitelisting rules for each client server IP address.

Define SLA Tiers in API Manager, apply the Rate Limiting - SLA Based policy, and require consumers to register client applications in Anypoint Exchange to request tier access.

Apply a standard Rate Limiting policy and hardcode client ID routing conditions inside a Choice router in the Mule application flow.

Apply a Basic Authentication policy and create custom user accounts in Anypoint Access Management for each client tier.

Test Your Knowledge

A developer is configuring API Auto-Discovery in a Mule 4 application generated by APIkit scaffolding. The application XML contains an HTTP Listener flow named api-main containing the apikit:router component, and several backend subflows named get:\customers:api-config, post:\customers:api-config, etc. To which flow must the api-gateway:autodiscovery element's flowRef attribute point?

To the global error handler flow to catch unauthorized policy exceptions.

To each individual backend implementation subflow using multiple autodiscovery elements.

To the main APIkit router flow (api-main) that receives incoming requests from the HTTP Listener.

To the http:listener-config global configuration element.

Test Your Knowledge

An API deployed behind the embedded API Gateway has both a Client ID Enforcement policy and a Rate Limiting policy applied. An external client sends an HTTP request with an invalid client_id header value. How does the API Gateway process this request?

The API Gateway evaluates security policies first, rejects the invalid credentials with an HTTP 401 Unauthorized response, and short-circuits execution before evaluating rate limiting or routing to the Mule flow.

The API Gateway decrements the rate limiting counter, forwards the request to the Mule flow, and lets APIkit return an HTTP 404 Not Found.

The API Gateway passes the request through to the backend database, which returns an SQL authentication exception.

The API Gateway executes all applied policies in parallel, aggregates their results, and returns an HTTP 500 Server Error.

Congratulations!

You've completed this section

Continue exploring other exams

Salesforce Certified MuleSoft Developer I

MuleSoft Certified Developer

12.3 API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

Key Takeaways

API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

1. API Manager Architecture & The Embedded API Gateway

Core Architectural Principles:

2. API Auto-Discovery Mechanics & Configuration

XML Configuration of Auto-Discovery

Mandatory Runtime Platform Properties

3. Standard Out-of-the-Box (OOTB) API Policies

1. Security Policies

2. Quality of Service (QoS) & Traffic Management Policies

3. Compliance & Content Transformation Policies

4. Policy Execution Ordering & Precedence Matrix

Policy Precedence Matrix Table

Short-Circuiting Mechanics

5. SLA Tiers, Client Applications & Exchange Contract Workflows

The 4 Steps of SLA Tier Management:

6. Managing APIs With a Separate Proxy Instead of Auto-Discovery

Choosing Between Them

7. Exam Watch: Core API Manager & Gateway Scenarios

Salesforce Certified MuleSoft Developer I

1Chapter 1: Creating Application Networks & API-Led Connectivity

2Chapter 2: Designing APIs with RAML & API Designer

3Chapter 3: Accessing and Modifying Mule Events

4Chapter 4: Structuring Mule Applications

5Chapter 5: Building API Implementation Interfaces

6Chapter 6: Using Connectors & External Systems

7Chapter 7: Processing Records & Batch Integration

8Chapter 8: Transforming Data with DataWeave 2.0

9Chapter 9: Routing Events & Flow Control

10Chapter 10: Handling Errors & Exception Management

11Chapter 11: Debugging and Troubleshooting Mule Applications

12Chapter 12: Deploying and Managing APIs and Integrations

MuleSoft Certified Developer

12.3 API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

Key Takeaways

API Manager: Auto-Discovery, API Gateway, SLA Tiers & Standard Policies

1. API Manager Architecture & The Embedded API Gateway

Core Architectural Principles:

2. API Auto-Discovery Mechanics & Configuration

XML Configuration of Auto-Discovery

Mandatory Runtime Platform Properties

3. Standard Out-of-the-Box (OOTB) API Policies

1. Security Policies

2. Quality of Service (QoS) & Traffic Management Policies

3. Compliance & Content Transformation Policies

4. Policy Execution Ordering & Precedence Matrix

Policy Precedence Matrix Table

Short-Circuiting Mechanics

5. SLA Tiers, Client Applications & Exchange Contract Workflows

The 4 Steps of SLA Tier Management:

6. Managing APIs With a Separate Proxy Instead of Auto-Discovery

Choosing Between Them

7. Exam Watch: Core API Manager & Gateway Scenarios