Cloud Blog

Category Archives: API Cloud

Meet WSO2 Cloud Team at WSO2Con US


In less than 2 weeks, we are hosting our main event of the year in the US – the annual WSO2Con in San Francisco, November 2-4. Along with the sister conferences in Europe and Asia, this is the main opportunities for us to meet the community of WSO2 users and partners, share roadmaps, and exchange ideas.

A lot of the WSO2 Cloud team members will be there and there are a lot of great sessions in the agenda.

There is a great session from our cloud technical leads: Amila and Chamith – on how we do DevOps for both public and managed cloud customers:


Myself and Imesh will talk about private cloud deployments, Kubernetes, Docker, and application PaaS technologies from WSO2:


I will cover WSO2 Cloud roadmap:


Imesh demonstrate multi-cloud container deployments:


Lakmal talk about the results of the recent big data in the cloud hackathon:


And finally Amila and Chamith provide details on cloud high availability and automation:


Plus, there will be many sessions on IoT, API Management, Integration, Security, and other hot topics of IT today.

There are still tickets available, so buy yours today, and we will see you in San Francisco the first week of November!

Prototype API in JavaScript in 2 Minutes

Successful companies try things fast, get feedback and iterate – and successful API programs are no exception.

WSO2 API Cloud makes prototyping a new API and running it by your users to collect feedback extremely easy.

All you need to do is:

  1. Define your API: list REST resources and parameters (either in our New API wizard or by importing or editing Swagger definition),
  2. Provide API definition

  3. On the second step of the wizard, pick the Prototype option and Inline to get JavaScript editor displayed with stub implementation in it,
  4. 2-inline-Javascript-prototype

  5. Modify the stub for each HTTP method you need to implement with your custom JavaScript code.
  6. 3-JavaScript-implementation-with-xml-output

  7. Deploy the prototype to your API store: your developers will start seeing the API, be able to invoke it, provide feedback, and so on.

Prototypes can also have versions so you can iterate on your prototypes as your vision evolves, and then substitute the implementation with real backend.

Here’s a video of the whole process – it literally takes less than 2 minutes!

And here’s the detailed tutorial.

Sign up for your free trial of WSO2 API Cloud now, and happy API programs!

99.99% – WSO2 Managed Cloud SLA Goes to Four Nines

99.99 - Guaranteed Uptime for WSO2 Managed CloudWSO2 Managed Cloud – our dedicated hosting offering – just got an upgrade. From now on, all Managed Cloud customers get financially backed 99.99% guaranteed uptime.

This is, of course, in addition to formal SLA on support ticket responses and all other niceties of the service:

  • Available for any combination of WSO2 products,
  • Run in the region of your choice on dedicated virtual machines not shared with any other customers,
  • WSO2 engineers set up the environment including the virtual machines, WSO2 products, and networking,
  • Can be set up to have network connectivity with your on-premise datacenter,
  • Deployment can be customized for your specific needs,
  • Can be combined with professional services including consultancy, development, and QuickStart,
  • Includes full devops service including 24*7 monitoring, regular backups, and product updates,
  • Priced as a fixed monthly fee.

You can find full updated SLA for WSO2 Managed Cloud at:

Fill out the form at the right side of the SLA page to get more information and sign up!

[NEW] API Cloud Custom URL for API Store and Gateway

API programs are key to building the ecosystem around your technology. Your developer portal and APIs represent who you are to your partners and customers. This is why branding is very important part of API efforts.

Branding for API programs consist of:

  1. Your own custom URLs for developer portal and APIs,
  2. Your logos, style, look and feel of the developer portal.

With the addition of custom URL functionality, WSO2 API Cloud now supports both kinds of customization.

1. Custom URL

By default, API Store for your subscribers gets a URL that looks like[your organization id], and the APIs themselves start with[your organization id]/.

My guess, is that instead, you would like a fully branded experience with API Store being available at something like and APIs at

Now all you need to do get there is:

  1. Come up with the nice URLs for both the API Store and the API gateway (and purchase the domain if you have not done so),
  2. Purchase SSL certificates for both domains (this is required because both portal and APIs themselves need to be accessed via HTTPS),
  3. In your domain registrar’s DNS panel, create CNAME records pointing to for APIs themselves, and for the developer portal,
  4. In WSO2 API Cloud, click the Custom URL menu and follow the configuration wizard.

Application overview page in WSO2 App Cloud

You can find detailed instructions in this tutorial: Customize the API Store and Gateway URLs.

2. Custom styles

Obviously, URL is just your first step. You also want the API store itself to be branded with your own corporate logos and styles.

This is as easy as taking our sample store theme, substituting the logos and any other graphics you want changed, and making proper changes to the CSS files.

Here’s a quick demo of the process:

And a link for step-by-step tutorial: Customize the API Store Theme.

Sign-up for a free trial of WSO2 API Cloud today!

[Video] Analyzing API Statistics and Blocking Rogue Subscribers

WSO2 API Cloud has all you need for successful API program. This means that besides just publishing your APIs and opening subscriber portal, you need to have detailed analytics reports to see the actual subscriber behavior and be able to block the subscriptions that do not comply with your policies.

We have published a couple of quick demos to show how this works.

Some of our out-of-box API analytics reports:

And here’s a quick video of how individual subscription can be easily located and suspended:

Start your free API Cloud trial today!

[VIDEO] New Publisher and Subscriber Experience in WSO2 API Cloud

With the latest updates to WSO2 API Cloud, we have made publishing and subscribing to APIs even easier!

Published APIs now just work out of box including interactive API Console (you no longer have to enable OPTIONS method for your APIs or edit Swagger file) – so the number of clicks to get your API published went down dramatically and the process became extremely straight-forward:

In subscriber portal (API Store) things got simpler as well. Interactive API Console no longer requires you to provide OAuth key manually and just grabs it from your configuration automatically. It also shows you various invocation and response details including the sample Curl command for your API call:

With these (and many smaller) changes and improvements, your API programs are now even more attractive and easier to implement.

Sign up for your free trial at

Your own JAX-RS as an OAuth Web API in Minutes!

UPDATE: This is an outdated post. WSO2 App Cloud has been since then replaced with WSO2 Integration Cloud and App Server in it with Tomcat. General principals still apply and JAX-RS is a supported backend implementation in the Integration Cloud. Click Support inside the Integration Cloud UI if you need help.

We’ll be using WSO2 Application server in Cloud to host a secured JaxRS service. A future post will explain how to do it with Tomcat, but this post is written for WSO2 App Server.

After writing the JAX-RS service we are going to protect it using OAuth with several clicks. Then you’ll be able to,

  1. Access to the back-end JAX-RS service will be OAuth protected
  2. Advertise the API in an API store for the world to see
  3. Access to the back-end JAX-RS service will be throttled
  4. Allow people to subscribe to these APIs

This is the high-level diagram,

Step 1 – Adding security to the JAX-RS service in App Cloud

Step 2 – Expose it as an OAuth protected API

Step 1 – Adding security to the JAX-RS service in App Cloud

Here I am going to add security to my JAX-RS service by introducing the following lines to the web.xml. As you can see this is plain Tomcat based security. And you have not defined a Realm here. I will explain what happens to the realm below.



Now only the people in admin role can call this service. If you are familiar with Tomcat security, the question is: where is the realm and is the role coming from? It is coming from the Cloud user store.


We have simplified a lot of security related details in WSO2 Application Server. Now let’s try to invoke it using a REST Client.

 curl -v -H   
 "Authorization: Basic Base64_encoded_String_of_your_Username:Password  

The trickiest part is figuring out the username. The “@” sign in the email address must be replaced with a “.”  and the tenant domain must be appended with the “@” sign. == becomes ==&gt;  

Here “perftest” is my tenant domain name.

Next, remember to turn off “http” from transports.

Step 2 – Expose it as an OAuth protected API from API Cloud

Now go into API Cloud and publish the JAX-RS as a service.

Add the proper resource URL patterns and end points. In my case I am going to add “customerservice/customers/{id}” as the url pattern and endpoint of the service as the endpoint. In my case, it is something as follows,

Give the username/password to access it.

Screen Shot 2015-08-24 at 1.49.35 PM

Woala you are done! Now you have an API in the store, that is accessible the whole wide world!

Disabling OAuth in API Cloud

OAuth2 has become the industry standard for secure API access, and is the default security mechanism that you get for your API subscribers in WSO2 API Cloud. API Cloud fully automates OAuth key generation and management.

However, there are circumstances when you might want to temporarily have your APIs available with no security required. For example, this might be the way you decide to launch them initially while you are still on the prototype phase.

WSO2 API Cloud gives you two ways of achieving this:

  • By publishing your API as Prototype, or
  • By setting required resource authentication level to None.

Publishing as Prototype

Prototypes are different from common published APIs because they are meant to run your ideas across your community to quickly collect feedback.

They can be implemented with a proper backend webservice (just like other managed APIs) or JavaScript.

Either way, they require no subscription. Your users will be able to give them a try without having to subscribe to them.

To publish an API as prototype:

  1. Pick Prototype on the second step of API creation (Implement),
  2. Provide JavaScript or backend URL,
  3. Click Deploy as Prototype.

Deploying an API as prototype (JavaScript or backend) on Step 2 of API implementation

The API will appear on the Prototypes tab of API Store and will not require authentication for access.

API prototype in WSO2 API Store

Authentication Type: None

You can also remove authentication requirements for regular managed APIs. This is useful when you want to still have the API listed on the API Store home screen and/or when you want to disable authentication requirement for individual resources of an API.

For that, go all the way till the last (Manage) step of API creation, and then change Authentication Type to None in the drop down next to each API resource at the bottom of the screen:

Setting REST resource Authentication Type from OAuth2 to None

Happy API management!

API Cloud upgraded to API Manager 1.9

Good news! We have just finished upgrading WSO2 API Cloud to the latest codebase of WSO2 API Manager (1.9) – which brings us the latest features and fixes.

The biggest improvement is full Swagger 2.0 support. Swagger is the industry standard for API definitions and this is what API Cloud is using natively as well.

You can not just import or export the Swagger definitions, but also edit your API in full-featured Swagger editor with intellisense tooltips, syntax checks, and so on. Simply click Edit Source on the first step of API editing:

Edit Source button on the first step of editing API

And you get the full power of Swagger at your disposal:

Swagger wysiwyg editor and tooling in WSO2 API Manager

There are many other improvements and fixes, and we will be now re-releasing our tutorial videos and publishing new blog posts covering the exciting new functionality. Stay tuned!

Sign up for free trial of WSO2 API Cloud at

API Cloud: Connecting to Backend Service with OAuth, Simple Auth, IP Whitelisting

WSO2 API Cloud provides a simple way to turn your web services into managed APIs with enforced policies, security, subscriber portal, and analytics.

To make this all work, all API calls from subscribers need to go through API Gateway rather than directly to your backend. See arrow 3 in the API Cloud schematics here:

cloud-api-diagram - how WSO2 API Cloud works

What this means is that you promote to your subscribers the API as it is published in the gateway and API Store, while securing the link between API Gateway and backend service.

There are a few ways that you can secure the connection between the gateway and the backend:

  • Unsecured access,
  • Simple username/password authentication,
  • IP whitelisting,
  • OAuth.

Unsecured Access is obviously the easiest. While not a good idea in the long run (if users are bypassing the gateway, you don’t really have an API management solution in place), but when you are only starting and experimenting, and have not launched the program yet – this is the easiest way to get started.

Because of that, this is the default mode and the one we are using in API Cloud tutorials.

Simple Username/Password Authentication is also very easy to implement. All you have to do is click Show More Options on the second (Implement) step of API implementation, select Secured from the drop-down list below it, and provide credentials:

Specifying credentials for backend API connection

IP Whitelisting is a good further security step. Simply contact our team via Support / Contact Us menu item, and we will give you the IP address range that we use for API gateway. That way you can set up your backend to only accept invocations proxied by the gateway.

Finally, if rather than username & password, your backend service only accepts OAuth2 authentication, we now have a fully documented way of using that approach. See this tutorial that we just published.

Happy API implementations, and let us know if you have any questions.


Recent Posts

Most Popular Posts