Getting started with MuleSoft Platform APIs and Postman automation in 15 minutes

They are known by many names: Anypoint Platform APIs, public APIs, MuleSoft’s Platform APIs, but what exactly are PlatformAPIs? Every time you login into Anypoint Platform, you are implicitly calling a set of APIs that are invoked by the UI, which are the PlatformAPIs! And here is the golden lingot: you can make these HTTP requests directly as well.

In Anypoint Platform we will be working with:

  • Design Center: Where you build your API Specification (RAML/OAS Contracts) 
  • Exchange: Where you publish that API Specification to create an Exchange Asset so that anyone in the organization can find, consume, and reuse them.

Building out the Use Case 

Now, let’s use an example scenario: one of the automation devs in our team is looking for a quick way to query Anypoint Platform to get a full list of applications and to query the status of a specific application, which then can be integrated in a pipeline, one of the requirements is to execute those through HTTP Requests. (Keep it mind for some cases Anypoint CLI, a wrapper of PlatformAPIs is enough!) 

Prerequisites 

Before we start working with platform APIs, you need these three pieces of data: a session token, the organization id and the environment id; as shown in the below image.

Make sure you have Postman installed, that you do know how to import the Postman Collection and the Environment and then you can finally download the postman assets from here. Import both files and make sure to add both anypoint-username and anypoint-password to your Postman Environment, the fields highlighted below.

Requests are CSRF protected, your Collections has the cookie clear script, but still, to avoid an invalid csrf token you need to open your Postman Cookies, Whitelist Domains and add *.mulesoft.com, if you need more help adding those Whitelist Domains see this article.

Setting up your environment 

First, execute the Login (/login) request. When successful, it will return the access token which will automatically be stored in your Environment variable api-auth-header

Run User Details (api/me) note the Header is the previous api-auth-header, when successful it will look like the screen below and the Root Business Group will automatically be stored in your variables as org-id (You can manually change the script or the variable if a different BG is needed).

Time for Environments (Get Env) Request, not the org-id in the URL. Select the id of the environment you want to work on and manually set the value for the environment-id variable.

Getting the list of applications and the application status

You can list all the applications available for the user in the business group in the environment. Run that List All request, first goal tackled, make sure you copy the domain value of the app you want to reveal next into the domain variable.

Let’s end up by using the List App to retrieve the specific information of an app, you can view the status, in this case, UNDEPLOYED.

Extra: Using the previous call, you can add/status at the end and will retrieve a string with the current status, as shown below.

Conclusion

Thousands of hours are wasted on manual usage of Postman. This blog article gives you a parametrized template where you can build upon for automation tailoring it to your needs and additionally you have ramped up with the Platform APIs. Was this helpful? Leave your thoughts below. 

For more developer resources, check out the Tutorials section of our website.



We'd love to hear your opinion on this post