// Apply a policy to an existing API Manager instance. Use when the user wants to add a policy, enforce security, configure rate limiting, apply OAuth2, set up IP allowlisting, or protect an API with any policy template from the catalog.
| name | apply-policy-to-api-instance |
| description | Apply a policy to an existing API Manager instance. Use when the user wants to add a policy, enforce security, configure rate limiting, apply OAuth2, set up IP allowlisting, or protect an API with any policy template from the catalog. |
Applies a policy to an API Manager instance by walking through organization and environment selection, picking the target API, browsing the available policy template catalog, configuring the policy using its JSON schema, and finally enforcing it on the API. The workflow ensures you select only templates compatible with your API instance and that the configuration matches the template's schema before applying.
What you'll build: A fully configured policy enforced on your chosen API instance
Before starting this workflow, ensure you have:
Authentication ready
Organization access
Retrieve the caller's profile to discover the root organization automatically. No parameters needed — the Bearer token identifies the user and returns their organization details, including any child Business Groups (sub-organizations).
What you'll need:
Action: Call the /me endpoint to get the current user's organization.
api: urn:api:access-management
operationId: listMe
inputs: {}
outputs:
- name: organizationId
path: $.user.organization.id
description: Root organization Business Group GUID
- name: organizationName
path: $.user.organization.name
description: Organization display name
What happens next: You have the root organization ID derived from your credentials. If your account has sub-organizations (child Business Groups), use getOrganizations with this ID to list them and pick the right scope before continuing.
List all environments in the organization so you can select the one where your target API instance lives (e.g., Production, Sandbox).
What you'll need:
Action: List available environments and select the target.
api: urn:api:access-management
operationId: listEnvironments
inputs:
organizationId:
from:
variable: organizationId
description: Organization ID from Step 1
outputs:
- name: environmentId
path: $.data[*].id
labels: $.data[*].name
description: Selected environment ID
What happens next: Choose the environment that hosts the API instance you want to protect. The environment ID is required by API Manager in all remaining steps.
Retrieve all API instances in the selected environment. Each entry represents a managed API registered in API Manager — this is the target you will apply the policy to.
What you'll need:
Action: List API instances and let the user pick one.
api: urn:api:api-manager
operationId: listOrganizationsEnvironmentsApis
inputs:
organizationId:
from:
variable: organizationId
description: Organization ID from Step 1
environmentId:
from:
variable: environmentId
description: Environment ID from Step 2
outputs:
- name: environmentApiId
path: $.assets[*].apis[*].id
labels: $.assets[*].apis[*].instanceLabel
description: The API instance ID to apply the policy to
What happens next: Present the API instances to the user. Each asset may contain multiple instances (e.g., different versions or labels). The user selects the specific environmentApiId to target.
Tips:
query parameter to filter by name if the list is largefilters=active parameter limits results to active instances onlyList all available policy templates from Exchange for your organization. This endpoint returns the full Exchange coordinates (groupId, assetId, version) and gateway-compatible configuration for each template — these are required when applying a policy.
Important: Use the api-portal-xapi endpoint (getExchangePolicyTemplates) instead of the generic listOrganizationsPolicytemplates endpoint. The generic endpoint does not return Exchange coordinates or gateway-specific configuration property names, which are required for the apply step.
What you'll need:
Action: List Exchange policy templates and select the one to apply. Pass apiInstanceId and environmentId to filter for templates compatible with your API's gateway type (e.g., Omni Gateway, Mule Gateway).
api: urn:api:api-portal-xapi
operationId: getExchangePolicyTemplates
inputs:
organizationId:
from:
variable: organizationId
description: Organization ID from Step 1
environmentId:
from:
variable: environmentId
description: Environment ID from Step 2
apiInstanceId:
from:
variable: environmentApiId
description: API instance ID from Step 3 (filters for compatible templates)
includeConfiguration:
value: "true"
description: Include the configuration schema for each template
latest:
value: "true"
description: Return only the latest version of each template
outputs:
- name: policyGroupId
path: $[*].groupId
labels: $[*].assetId
description: Exchange group ID of the selected policy template
- name: policyAssetId
path: $[*].assetId
description: Exchange asset ID of the selected policy template
- name: policyAssetVersion
path: $[*].version
description: Exchange version of the selected policy template (gateway-compatible)
- name: policyConfiguration
path: $[*].configuration
description: Configuration schema with gateway-compatible property names and defaults
What happens next: You have the policy template's Exchange coordinates and its configuration schema with the correct property names for your gateway type. Review the policyConfiguration output to understand what settings the policy accepts before applying it. For each configuration property, present the user with the property name, its description, and the default value, then ask if they want to keep the default or provide a custom value. If a property has no default, always ask the user for a value.
Common issues:
apiInstanceId and environmentId to get templates compatible with your gateway type. Without these filters, some templates may not appear.listOrganizationsPolicytemplates endpoint may return different (non-gateway-compatible) property names and defaults. For example, Omni Gateway uses credentialsOriginHasHttpBasicAuthenticationHeader while the generic template uses credentialsOrigin.Apply the selected policy to your API instance with the appropriate configuration. Use the Exchange coordinates and configuration property names from Step 4.
What you'll need:
policyConfiguration outputAction: Apply the policy to your API instance. Build the configurationData object using the property names from Step 4's configuration schema. For each configuration property, present the user with the property name, its description, and the default value, then ask if they want to keep the default or provide a custom value. If a property has no default, always ask the user for a value.
api: urn:api:api-manager
operationId: createOrganizationsEnvironmentsApisPolicies
inputs:
organizationId:
from:
variable: organizationId
description: Organization ID from Step 1
environmentId:
from:
variable: environmentId
description: Environment ID from Step 2
environmentApiId:
from:
variable: environmentApiId
description: API instance ID from Step 3
groupId:
from:
variable: policyGroupId
description: Policy Exchange group ID from Step 4
assetId:
from:
variable: policyAssetId
description: Policy Exchange asset ID from Step 4
assetVersion:
from:
variable: policyAssetVersion
description: Policy Exchange version from Step 4
outputs:
- name: policyId
path: $.id
description: The ID of the applied policy instance
What happens next: Your API is now protected with the selected policy. Incoming requests will be evaluated against the policy rules. You can verify by listing the API's applied policies or testing a request.
Common issues:
getExchangePolicyTemplates (Step 4) to get these values.policyConfiguration output, not from the generic template endpoint. For example, Omni Gateway uses credentialsOriginHasHttpBasicAuthenticationHeader while the generic template uses credentialsOrigin.?allowDuplicated=true to the request URL to apply a second instance of the same policy type.After completing all steps, verify the policy is properly applied:
✅ Policy Enforcement — The selected policy template is now active on your API instance, configured with the parameters you provided. Incoming traffic is evaluated against this policy.
Verify the policy — List applied policies with listOrganizationsEnvironmentsApisPolicies to confirm it's active and correctly configured.
Test the enforcement — Send requests to the API and verify the policy behaves as expected (e.g., unauthorized requests are rejected, rate limits are enforced).
Adjust configuration — Use patchOrganizationsEnvironmentsApisPolicy to update configuration without removing the policy.
Apply additional policies — Repeat this workflow to layer multiple policies (e.g., add rate limiting on top of OAuth2). Use updateOrganizationsEnvironmentsApisPoliciesBulk to control execution order.
Consider automated policies — If you want this policy applied to all APIs in the organization automatically, explore createOrganizationsAutomatedpolicies.
Symptoms: Requests pass through without policy evaluation
Possible causes:
Solutions:
pointcutData — omit it to apply to all endpointsSymptoms: "The policy to be created is missing at least one of the following properties related to the policy template: 'groupId', 'assetId', 'assetVersion'."
Possible causes:
listOrganizationsPolicytemplates endpoint which does not return Exchange coordinatesSolutions:
getExchangePolicyTemplates from api-portal-xapi instead — this returns the full Exchange coordinates needed by the apply endpointSymptoms: 400 error with invalid configurationData
Possible causes:
configurationDataSolutions:
configuration output from getExchangePolicyTemplates (Step 4) — it returns gateway-specific property namescredentialsOriginHasHttpBasicAuthenticationHeader while the generic template uses credentialsOriginSymptoms: Empty results in Step 4
Possible causes:
apiInstanceId or environmentId filtersSolutions:
apiInstanceId and environmentId to filter for compatible templateslistOrganizationsCustompolicytemplatesDiscover and navigate the Anypoint Platform API developer portal to find APIs, agent skills, and schemas. Use when bootstrapping knowledge of the Anypoint Platform, onboarding to the API ecosystem, finding available APIs, understanding the portal structure, resolving URNs, looking up JTBD skills, understanding x-origin dynamic parameters, or planning multi-API workflows.
Secure an agent by applying a policy from the catalog. Handles multiple starting points: from an existing API Manager instance, from an agent asset in Exchange, or from scratch by publishing the agent first. Use when the user wants to secure an agent, add rate limiting, apply OAuth2, enforce IP allowlisting, or protect any agent with a policy — regardless of where they are in the setup process.
Secure an API by applying a policy from the catalog. Handles multiple starting points: from an existing API Manager instance, from an Exchange asset that needs an instance, or from scratch. Use when the user wants to secure an API, add rate limiting, apply OAuth2, enforce IP allowlisting, or protect any API with a policy — regardless of where they are in the setup process.
Secure an MCP server by applying a policy from the catalog. Handles multiple starting points: from an existing API Manager instance, from an MCP server asset in Exchange, or from scratch by publishing the MCP server first. Use when the user wants to secure an MCP server, add rate limiting, apply OAuth2, enforce IP allowlisting, or protect any MCP server with a policy — regardless of where they are in the setup process.
Workflow required before any Mule flow and integration work. Call use_skill as your FIRST action — before reading project files — whenever the user asks to create, generate, update, fix, modify, change, edit, tweak, adjust, or rework any Mule flow, sub-flow, or component. Do not read project files and attempt the change yourself — even targeted single-component changes like 'modify the choice router', 'fix the until-successful', or 'update the catch block' require this workflow. Covers all change types, new integrations and targeted changes to error handlers, catch blocks, choice routers, DataWeave transforms, HTTP listeners, foreach loops, retry policies, scatter-gathers, connectors, and variable assignments. Prompts beginning with 'This code defines...' or 'This flow...' are generation requests, not analysis. When you call this skill, it must be the only tool call in that response.
Workflow for generating MuleSoft projects from Anypoint Exchange templates, local .jar templates, or from scratch via the `mule-mcp-server`. Use when users ask to "create a project", "generate project", "build integration", "create API", "use template", or "from template". Performs template discovery and calls create_mule_project only after explicit user confirmation; delegates flow generation to the `build-mule-integration` skill.