About Resource Level Policies

Using Mule 3.8.1 and later, you can apply one or more out-of-the-box policies to the resource- and method-level of an API that meets the following conditions:

  • The API has a RAML endpoint.

  • You create the API using APIkit or a RAML proxy.

Using APIkit, you create a RAML-based API and configure a Basic Endpoint, or you create the RAML-based API and configure the Endpoint with a Proxy in the case of an existing API.

A policy applied at a resource level affects selected methods within the resource. You need to add some code to existing custom policies to support this capability.

Unsupported Policies

You cannot apply the following policies to resources:

  • Cross-Origin Resource Sharing

  • LDAP Security Manager

  • Simple Security Manager

Usage Scenarios

The uses for resource level policies are limited mainly by your imagination. Here are a few possibilities:

  • Applying policies to specific resources

  • Securing a subset of an API

  • Setting different limits on resources

The following sections describe how to apply policies to resources and methods that appear in the API simulation example:

API Console displays resources and methods

Applying Policies to Specific Resources

A resource level policy supports Java regular expressions. For example, you can use the wildcard to apply a policy to multiple resources. When you apply the policy to the API, specify the resources to which it applies.


See To Apply Policies and SLA Tiers for an example of applying policies at the resource level using a simple regular expression.

Do not use a placeholder, such as {userid}, in the regular expression. Using a placeholder in an expression fails because the placeholder does not match the actual node. In the case of the example placeholder {userid}, the node actually looks something like this:


  • 671962fc-f076-4b19-bc38-45ba3a4e4095 is the user ID

  • 1234 is the ID of a permission

To apply a policy to resource /api/users/{userid} that represents a single user and all nodes below the resource, use the following expression:


To apply a policy to only the permissions resources /api/users/{userId/permissions} and /api/users/{userid}/permissions/{permissionId}, use the following expression:


Securing a Subset of the API

You can add security to create, update, and delete operations, leaving read-only operations unsecured. For example, you want to apply an HTTP basic authentication policy to specific methods and resources. Select POST, PUT, PATCH and DELETE methods and use the following expression to cover every resource URI of the API:


This expression enforces security on write operations, leaving GET (read-only) unsecured. Use a more specific expression to covering just a subset of the resources.

Setting Different Limits on Resources

You can enforce rate limiting to user-specific operations with different limits depending on the user action. You can apply rate limiting, for example, multiple times, limiting requests to a greater extent for some resources than others. For example, you can set different limits for read, create, and delete operations per user on the following nodes:

 /api/users/.*/.* →

First, you apply a rate limiting policy to specific methods and resources, selecting the GET (read) method and using the following regular expression:


You then configure the policy to limit requests to 100 requests per 1 hour, for example.

Next, you apply the rate limiting policy to specific methods and resources again, but selecting the POST (create) method and using the same regular expression as before. Configure 50 requests per 1 hour.

Finally, you can apply the rate limiting policy again to specific methods and resources, selecting the DELETE method. This time, you use and the same regular expression as before. For example, you can configure 25 requests per 2 hours.