The Mule Enterprise Console REST API


When building Mule architectures a company will often need to run several instances of Mule ESB: Some on QA, some on staging, and on production, perhaps some instances running locally and some others in another continent. Managing Clusters of Mule Servers, keeping track of what application is running where, and knowing what is the health of those instances at a glance, or even being warned when something wrong happens… That is Mule Enterprise Console job!

So you can use the UI to manage all your geographically distributed instances, but what about automation?

Yes UI is good, but…

  • You would like to integrate this with your headless continuous build so as soon as you have a new binary, that binary is automatically deployed into QA environment
  • You would like to make sure that binaries deployed on production are the ones built by your continuous build solution, so assert that by  running  against it your security algorithm and then you deploy it
  • You would like to create a  made of your existing Mule instances. And then, be able to deploy applications and manage them and their flows programmatically
  • You would like to be able to control which versions of the applications are deployed. In fact you would like to monitor that and do some polling by the way of your system, that knows how to manage scripting.
  • You would like to deploy some applications to a set of servers and clusters (ie. Server Group) and let the system manage the complexity of deploying apps into each of the member of the Server Group. But wait! For security reasons application is on the server, no FTP allowed, neither a UI.

These tasks, among others, can be performed using Console’s REST API.

 Introducing the Mule Enterprise API

The REST API has an important concept here, representations of resources (eg. servers, clusters, security groups), each of which can be identified using an URI.

Once you have a resource identified you can operate over it using a limited set of instructions (ie HTTP verbs). In this phase of the project, all resources are represented using JSON (JavaScript Object Notation) representation, which has parsers in almost any language, and is human readable too.

Quick summary of Operations

  • Register new Mule Servers and manage existing ones, including restarting/stopping  servers, as well as managing files remotely and even managing flows and their endpoints belonging to deployed applications
  • Manage Server Groups, so you have a single point of and you can forget about you geographically distributed environments
  • Manage User Groups and, in particular, the permissions assigned to them
  • Create or remove a Cluster and get information about a cluster, as well as start, stop, and restart applications on it
  • Find, upload, and delete applications inside the Repository, so and application and its different versions will be available when doing a deploy or redeploy
  • Deploy, undeploy, create, update, and delete Deployments inside a Server or Cluster

For further information, and usage examples, you can take a look at the Console’s REST Reference Guide.

We'd love to hear your opinion on this post

7 Responses to “The Mule Enterprise Console REST API”

  1. Do you have any thoughts/examples on how best to script this and integrate it with a continuous build process? e.g. using Maven? or UNIX shell?


  2. Hi Robert! Regarding your question I can tell you what we do at the project. We have chosen the Maven approach. Using Cargo Maven plugin and a Mule extension for Cargo ( we deploy the Console into one supported Web Container (eg Tomcat 7), we start a Mule instance with the agent listening on a port that is free at the time of Maven execution (we use Failsafe and build-helper-maven-plugin to determine such a port), and then we use a Jersey client to make all necessary calls to the Console REST API. Actual business logic is separated from REST calls (highly reusable code) .

    Here are some code fragments that can be of help:


    import org.codehaus.jackson.jaxrs.JacksonJsonProvider;

    import com.sun.jersey.api.client.Client;
    import com.sun.jersey.api.client.ClientResponse;
    import com.sun.jersey.api.client.WebResource;
    import com.sun.jersey.api.client.filter.HTTPBasicAuthFilter;
    import com.sun.jersey.api.client.filter.LoggingFilter;

    public ServerListResponse getServers() {
    return new ServerListResponse(client.getSimpleGetResponse(“servers”));

    public ClientResponse getSimpleGetResponse(String path) {
    final WebResource.Builder resource = getJsonClient(path);
    final ClientResponse clientResponse = resource.get(ClientResponse.class);
    return clientResponse;

    public WebResource.Builder getJsonClient(String urlPath) {
    final Client client = getClient();
    return client.resource(“http://localhost:8585/mmc/api/” + urlPath).type(MediaType.APPLICATION_JSON_TYPE);

    private Client getClient() {
    final DefaultApacheHttpClientConfig config = new DefaultApacheHttpClientConfig();

    final Client client = ApacheHttpClient.create(config);
    client.addFilter(new HTTPBasicAuthFilter(user, password));
    client.addFilter(new LoggingFilter());
    return client;

    – ‘http://localhost:8585/mmc/api/’ can be changed/parameterized depending on your system (eg ‘http://myhost:8080/muleconsole/api/’)
    – For basic tests you can use user/password: admin/admin


  3. The previous comment was more about a mix between Java and Maven. If you prefer a pure Maven approach for, let’s say, continuous deployment, you can use also the Maven Mule REST plugin ( that offers you a subset of Console’s REST capabilities through a pure Maven approach.


  4. Thanks for your help! I’ll check out the pure maven route first, but I quite like the idea of a Java wrapper to facilitate common tasks which could then be easily integrated into our non-maven deployment scripts. Groovy is another route too.


  5. […] The Mule Enterprise Console REST API […]

  6. Thanks Nahuel for putting this up. Infact, I started using this currently to integrate with our process and the CI tool (anthill). While going through the API I see that lot of time we need to create a deployment id which is a UUID and cannot be memorized. If you don’t have a deployment id you cannot proceed with deployment, as the id is used in the URL signature.
    I suggest , like for cluster and servers you have id and names. Can there be names for Deployments too?

    • Hi Nishant! Using the deployment ID has many benefits as it is (among them, you can choose any name for the deployment, otherwise you’ll need to encode special characters, for example the space, and the final result would not be very user friendly). The API is oriented to be used programmatically. In that regard, you don’t need to use any mnemonic as deployment name, because full access can be achieved by using the deployment ID. For example, when you create a deployment the returned JSON contains the deployment ID or even better, the href of the resource (eg “href”: “http://localhost:8080/mmc/api/deployments/local$97e3c184-09ed-423e-a5a5-9b94713a9e36”) then you append to it “/deploy” and perform a POST, and your deployment is deployed. No need to involve a human here.
      Now, lets say that name of the deployment is the only thing known about the deployment. Then, programmatically, you can iterate over all deployments (you can filter them by server on the list all rest call), and look for name matches. If you have a unique result, then you can extract the ID from it and continue operating with that value from that point on.