Cloud Blog

Category Archives: API Cloud

SOAP to REST made easy

WSO2 API Cloud has been a service which allows you to convert your SOAP backends to RESTful, managed APIs as a first class feature. We have published a previous blog post on this and we do have a tutorial too which provides step-by-step instructions on how to get it done. API Cloud is capable of doing this because of the mediation capabilities of the API gateway. This has been a widely used feature so far. But, there were some steps which we thought we could improve. As a result of that, exposing your SOAP backend as a RESTful, managed API now has been made very easy.

Following are the improvements we have done.

  • Previously, users had to create the resources of the API manually. But now, when you provide the WSDL url, API publisher automatically creates the resources by looking at the SOAP operations in the WSDL. Users can then edit the Swagger definition and make changes to the resources names, HTTP verbs etc. if needed.

  • Previously, users had to upload a custom mediation sequence to generate the SOAP payload to be sent to the SOAP backend. Now, this mediation sequence is auto generated by the publisher app and users can change it if needed.

Following is all you have to do after going to the API publisher:

  1. Create an API by providing the WSDL url of your SOAP backend.
  2. Publisher will generate the swagger definition. Edit it as necessary.
  3. Provide the backend service url in the Implement tab.
  4. Edit the mediation sequences which does the SOAP to REST mapping as necessary.
  5. Publish the API.

You can follow our documentation with more detailed steps.

WSO2 Named a Leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report

You may already know that WSO2 API Cloud is powered by the world class open source product “WSO2 API Manager”. When you access the API Cloud, what you get is the hosted latest version of WSO2 API Manager which spans through multiple geographical regions. We are happy and proud to announce that WSO2 was named as a leader in the Forrester Wave for API management solutions, Q4 2018 report. You can download the report (without filling a form) by going to our site.

It is a great achievement for WSO2 to be identified as a leader in API management. This means you are consuming a world leading API management solution when you use the API Cloud.

So, why wait? Try it out today for your API management project too.

Log download feature improved with HTTP access logs

In June 2018, we launched the log download feature for WSO2 API Cloud users. It allowed the users to download the logs of the cloud API gateways. This has been useful to many of our users when investigating and troubleshooting certain issues they face.

We are happy to announce that we have now added the capability to download the HTTP access logs (load balancer logs) of the APIs as well. These logs includes the request paths and the response codes (which you find in normal access logs)  associated with the API requests coming to the cloud API gateways.

When you go to download the logs, you will get an option to select from Gateway and Load Balancer.  Rest is the same steps as in the log download feature.

Next time if your API consumers complain about some of the API requests, these logs will help you to troubleshoot them.

Configure the header to carry the Bearer token

APIs published on the WSO2 API Cloud are secured using OAuth2.0 by default. Any client application invoking a secure published API needs to have a valid subscription to the particular API and present a valid OAuth2.0 Access Token to the API Gateway.

The HTTP Authorization header is the most common method of providing authentication information for REST APIs and it is used in API Cloud as well. The application needs to have the access token in the Authorization header to authenticate the API that is being accessed. But, there can be reasons such as organizational policies, legacy backends expecting to use the authorization header for other purposes and legacy client applications which will force you to use some other header to pass the bearer token to the API gateway.

WSO2 API Cloud now allows you to define your own header to carry the bearer token. This can be configured for the entire organization (all your APIs) or for certain APIs only.

Configure the authorization header per API

When creating a new API or editing an existing API,

  1. Go to the “Manage” tab in the UI.
  2. Provide the name of the header which you wish to use as the authorization header as shown below. 
  3. Save and publish the API.
  4. When you go to the developer portal, you will be able to see the portal is ready to send the new header to the gateway.

If you want to invoke the API with cURL, following is the command.

curl  -X GET “<Your API URL>” -H “Accept: application/json” -H “Token: Bearer <Your Token>”

Read our documentation to learn how to configure this at the organization level.

Now that this cool feature is available in the WSO2 API Cloud, you will be able to connect your legacy backends and legacy clients to the API gateway without worrying about the authorization header.

.entry-content img {
width:100% !important;

How to Download API Cloud Logs

Logs are an important part of troubleshooting and WSO2 API Cloud has long had a live log viewer giving you access to what is going on in your cloud API gateway. Today we are happy to announce that we have also added the ability to download historical logs (older than 30 minutes).

To access your historical logs:

1. In API Cloud, click the Configure / Admin Dashboard menu.

2. In Admin Dashboard, navigate to Log AnalyzerDownload Logs and pick the date for which you need the log files:

3. In a few minutes, API Cloud will give you a link to a zip archive with your logs. Go ahead and download the zip right away – the link automatically expires in about 5 minutes.

This new feature is available at no additional cost and with no extra configuration to all customers at subscription levels Medium and higher.

CI/CD for APIs and Backend Implementations

Agile development of production APIs requires their inclusion in the Continuous Integration (CI) / Continuous Deployment (CD) process:

  • Merge the implementation into a shared repository and have it automatically verified,
  • Automated pipeline deploying the changes into multiple environments such as test, staging, pre-production, production.

WSO2 API Cloud is fully automatable via APIs including API export and import, and other configuration aspects. This makes it easy to integrate API Cloud-based gateway into whatever CI/CD platform you are using.

Also, in most cases, you would want you CI/CD process for APIs to be a part of the process that you have for API backend implementation. This ensures that these two evolve consistently.

While all platforms are different, we have published a reference implementation that uses GitHub as the code repository, Travis as the CI/CD platform, and WSO2 Integration Cloud as the backend hosting platform:

Check it out, adapt to your process, and let us know what you think!


Role-Based API Editing Rights

The new feature that we have just rolled out allows teams to separate who can edit and publish which APIs.

Suppose you have a fairly large project or even a set of projects and they have different APIs. The chances are that different APIs are owned by different teams. Up until now, there was no way to let teams edit and publish just their APIs and not APIs belonging to their colleagues.

Now all you have to do is:

  1. Set up the roles for each team and add their members to the roles,
  2. Ask the teams to set their APIs’ Access Control setting to Restricted by roles, and then provide their role name in the Visible to Role field (both of these can be found at the Design step of API editing):

This new feature nicely compliments the ability to select which subscribers can see which APIs in the Developer Portal (API Store).

Give the new feature a try in WSO2 API Cloud and let us know what you think!


API mediation cookbook

API Cloud comes with a powerful mediation engine that can transform on the fly requests to the backend as well as the responses coming back.

Our cloud team went through all the support requests on custom mediation flows that we had over the years and published the most popular sequences in our documentation for you to re-use.

Check them out:

Also, see this page for instructions on uploading your sequences.

And finally, don’t hesitate to use the Support menu to ask any questions or request assistance. We are here to help!


Programmatically download API usage statistics

WSO2 API Cloud has a rich set of reports built in. In addition to that, we have now added the ability to programmatically pull API invocation data via a REST API so you can do your own reporting and integrate it with your other systems.

For this example, I will pull down statistics on the API calls that I made on a particular day. Here’s how:

1. Follow our earlier blog post to register your client and obtain your OAuth token (steps 1 and 2 in that blog post).

Important: on step 2.3 (Request the token), make sure to use apim:subscribe as the scope:

$ curl -k -d "grant_type=password&username=email@org_key&password=pwd&scope=apim:subscribe" -H "Authorization: Basic Base64EncodedclientIdclientSecret"


2. Invoke the statistics API:

2.1 Create a json file with the parameters – the timeframe and the statistics ID:

  • getTopAppUsers – Top Users For Applications
  • getAppApiCallType – API Usage from Resource Path
  • getPerAppAPIFaultCount – Faulty Invocations per Application
  • getProviderAPIUsage – API Usage per Application

For example, here’s the stat_payload.json that I used:

    "statisticsType" : "getProviderAPIUsage",
    "toDate":"2018-02-02 00:00",
    "fromDate": "2018-02-01 00:00"

2.2 Invoke the API to get the stats:

$ curl -X POST -H "Authorization: Bearer fac22c3b-efc1-3c16-92e8-56ab96a0f2f6" -H "Content-Type: application/json" -d @stat_payload.json

  "message":"Successfully retrieved the statistics data for the statistics type getProviderAPIUsage for the user",
       \"appName\":\"Default Application\",
            \"apiName\":\"Heroes (\",
            \"apiName\":\"Phones (\",
            \"apiName\":\"WorldBank (\",

This is just one of the APIs that WSO2 Cloud exposes. To see all other APIs, check out our documentation.




API Gateway add-on for Heroku PaaS

Heroku is one of the most popular platform-as-a-service (PaaS) systems used by many developers to deploy, manage, and scale their applications. Recently, Heroku and WSO2 worked together to add API gateway and management functionality to the platform. In this blog post we will look into what it is and how it works.

What is API Management?

In today’s interconnected world, it is very rare that and app or a service exists by itself and is not part of a wider ecosystem of other applications. Services access other services, are part of wider ecosystems, serve as backends for web- and mobile applications.

When this happen, the services are exposed as APIs (application programmable interfaces) and the API management layer that enables that typically includes:

  • API publishing tools: ability to design, prototype, import, and test APIs, work on new versions of APIs and manage their lifecycle,
  • Security and policies: define who can access the APIs, manage their OAuth keys, set roles and scopes, as well as throttling and rate-limiting tiers,
  • Orchestration and on-the-fly transformation: your external API representation can be decoupled from your backend interfaces, and the gateway can transform the incoming calls and data formats into what your backend needs, as well as the other way around,
  • Developer Portal: the API store website for your ecosystem developers to locate the APIs, try them, read the documentation, subscribe, manage their OAuth keys and so on,
  • Monetization: ability to sell APIs and charged based on their usage,
  • Analytics: reports and alerts to give you visibility into how your APIs are used and notifications when something is not right.

API Management Add-On in Heroku

API Management add-on is now part of the Heroku Elements marketplace and provides the fully functional API management wrapper around your Heroku services with all the features we mentioned earlier.

Today we will discuss the scenario in which the gateway stays outside of the Heroku deployment working as an external layer securing the access and enforcing the policies:

Let’s explain how each of the components work:

  • Backend services in Heroku: no big changes there, you run them just like you did before. What you would want to do is to protect the backend from direct access from the internet so API gateway can send traffic to the backend but no one can bypass it. You would typically do this with a combination of basic (or digest, or mutual SSL) authentication, and (if you have Heroku Private Spaces) VPC peering and IP restrictions.
  • API Gateway: this can be run as a dyno or can stay external inside WSO2 API Cloud. You configure the gateway to get secure access to the backend, expose the APIs, set up the policies and transformations to be applied. Also, even when the gateway stays in API Cloud, you would typically want to pick the same AWS datacenter that your Heroku backend is using – this will minimize the network overhead and improve performance.
  • User interfaces: these stay in API Cloud and require no deployment. Once you provision the add-on, you get single sign-on into the web UI for API management and analytics. You also get the Developer Portal that you brand and customize, and that becomes the web site that your subscribers use.

Getting Started

To enable the add-on for your Heroku application simply run the following Heroku command line:

heroku addons:create wso2apicloud

To open the API management configuration UI in your browser, run:

heroku addons:open wso2apicloud

You start at the free usage and can then upgrade to the tier that fits you best.

See Heroku API Management add-on documentation for detailed tutorial.


Recent Posts

Most Popular Posts