Cloud Blog

Category Archives: API Cloud

WSO2 Cloud Incident Report: Jan 12, 2016

WSO2 Cloud experienced a serious service degradation on 12th January 2016: users were not able to login to the cloud for few hours.

Start time: 12th January 2016, 0833 PST
Recovery time: 12th January 2016, 1217 PST


  • Users were not able to log into the cloud,
  • Sign-up was not working,
  • API Gateway was functioning throughout the incident serving API calls at normal performance level. There was only a 5 minute gateway downtime during database restart:

Root cause:

  • One of the housekeeping tasks running in our Identity Servers has failed due to a failure in acquiring a lock on a database table. This locked table is also responsible for storing the sessions and since it was locked, system was not able to complete the new user logins.
  • Since it was not possible to find out, which component was keeping the table locked, we had to restart the database server to get the system back on track.


  • We have decreased the frequency of the aforementioned housekeeping tasks as advised by our Identity Server team.
  • We have also raised a support ticket with our internal support team to fix any possible future failures for this task.
  • We are investigating further to figure out which component had the table locked and to fix it.
  • We are looking into alerting and maintenance processes to ensure quicker resolution time in the future.

How to avoid your backend endpoint getting suspended by the API Gateway

When invoking an API published in API Cloud, you might have seen the following error response:

<am:fault xmlns:am=""><am:code>303001</am:code><am:type>Status report</am:type><am:message>Runtime Error</am:message><am:description>Currently , Address endpoint : [ Name : somename-AT-sometenant--test_me_APIproductionEndpoint_0 ] [ State : SUSPENDED ]</am:description></am:fault>

As you can see from the message above, the endpoint got suspended. By default, gateway suspends API for 30 seconds when it cannot reach the endpoint. So, if another request comes to your API within that 30 seconds, it won’t be sent to the backend, rather an error response similar to above will be sent back to the client.

If this is not the behavior you want, these rules are simple to modify:

1. Go to API Publisher and select the API that you want to change. Then click Edit from API Overview

2. Under the Implement tab, select Advanced Options on the endpoint which you want to re-configure.


3. Modify the values. If you want to disable the suspension rules, set both Initial Duration and Max Duration to 0:


4. Save changes and re-publish the API.

This way you can tweak the suspension rules or completely disable the mechanism and thus prevent your API from ever getting suspended by the API gateway.

Try it today in WSO2 API Cloud!

[Video] Configuring Self-Signup for API Store

What is your strategy on bringing subscribers to your API Store?

While internal and select-partner API programs likely only want to invite developers manually, there are many public API programs in which publishers would like developers to be able to find the developer portal and sign-up themselves.

There is also a variation of the latter case, in which you want anyone to be able to submit a request to join the community, however administrator needs to approve the request before the developer can join.

WSO2 API Cloud supports all three scenarios:

  1. No one can sign up, members are invited by admin – this is the default mode,
  2. New members can sign up, but need to be approved by admin,
  3. New members can sign up and get immediate access.

To enable scenarios 2 and 3, click the Configure / API Store Access menu in API Cloud, and follow the instructions.

Below is a quick video demonstrating the whole process:

If you prefer to read step-by-step instructions instead, you can find them in our documentation: Enable Self-Signup to the API Store.

Try it in WSO2 API Cloud today!

Happy Holidays from WSO2 Cloud Team

From all of us at WSO2 Cloud team, we are wishing you the most joyful holiday season and an amazingly happy new year!

WSO2 Cloud Holiday Card 2016

2015 has been a great year for us with the successful production launch of WSO2 API Cloud, its rapid adoption by many companies, and the many features we have rolled out through the recent months: uptime dashboard, interactive tutorial, firewall compatibility, custom URLs, API store branding, custom publisher information – to name just a few.

We look forward to hosting your APIs and applications in 2016 and beyond!

Happy Holidays!

API Cloud Uptime Dashboard

It just became easier to see if we follow our 99.9% uptime SLA for WSO2 API Cloud. We launched a public Uptime Dashboard at

WSO2 API Cloud Uptime Dashboard

The dashboard is provided by Pingdom so it is independent of WSO2. Note that the reported performance includes not just the actual WSO2 API Cloud response time but also the network latency, as Pingdom tests are done from multiple locations across North America and Europe.

Want a reliable transparent API management solution with guaranteed SLA – try WSO2 API Cloud.

API Gateway Default Ports are now 80/443

When WSO2 API Cloud launched initially, by default API Gateway was exposing APIs on ports 8280 and 8243. For customers with firewalls blocking these ports, this led to calls failing with { "error": "no response from server" }.

The workaround that we had for this was using Custom URL functionality – which changed both the Gateway URL and ports.

Now we made things even better, and no workarounds are required anymore:

From now on, default network ports for API Gateway are the standard port 80 for HTTP and port 443 for HTTPS – so things just work with no extra configuration required:

Default ports in WSO2 API Cloud

Note: for backward compatibility we will keep the old ports 8280 and 8243 also available for another couple of weeks. However, as we will be decommissioning their support in the future, all customers are advised to switch to ports 80/443.

Try the new functionality in WSO2 API Cloud now!

API Cloud Interactive Tutorial

Too busy to read documentation or watch videos? No worries, WSO2 API Cloud now has interactive step-by-step tutorial that leads you through publishing your first API (based on the countries data from the World Bank) and invoking it from API Store:

Interactive walkthrough tutorial for WSO2 API Cloud

Friendly callouts tell you where to click and what to type – so within a couple of minutes you get a pretty good understanding on how API design, publishing, and subscriptions work!

If this is the first time you log into API Cloud, the tutorial will start automatically.

Already have an account? No worries, you can always start the tutorial manually from Documentation menu:

Documentation - API Cloud Walkthrough menu

Your first published API is just a few minutes away! Sign up for a free trial or log into your existing WSO2 Cloud account, and give it a try!

[Video] Setting up custom URL for API Store and Gateway

Your company URL is an important part of your developer community experience. There are two scenarios in which subscribers see URLs and both are supported by WSO2 API Cloud:

  • The URL under which the API Store (developer portal) is available,
  • Gateway URL that is the base URL for your APIs.

Customizing them follows the same pattern:

  1. Map CNAME record for your custom URL to API Cloud custom DNS endpoint:,
  2. Configure API Cloud to accept these URLs and upload SSL certificates.

We have created a quick video that shows the entire configuration process including creating CNAME records and obtaining SSL certificates:

If you prefer to read a step-by-step tutorial, you can find it here.

Start your free WSO2 API Cloud trial today.

Custom API Publisher Info for Your APIs

Your subscribers need to know who is behind the APIs that they consume. Depending on your scenario, you might want to set the API owner information to the individual who published the API, a particular team in your company, or just the company itself. WSO2 API Cloud lets you easily implement any of these approaches.

By default, API Store will display the internal name of the individual who published the API:


To change it to your team name or company name, simply provide the proper name at the last step of API editing wizard:

Provide API owner information

Once you publish the API with the owner information filled in, API Store starts reflecting the new owner information in the user interface:

Customized API business owner

This is just one of the ways you can control your branding and the way your subscribers see your company.

See also this post on changing API Store styles, logos, and URLs.

Get your free 2 week API Cloud trial today!

The Power of Mediators: API Call Transformation and Orchestration

Sometimes you are lucky and the backend web services match exactly your desired public API design. But what if they do not? What if you need to change formats on the fly? Or do XSLT transformation? Or orchestrate multiple backend services called and joined into a single API?

Fear not! WSO2 API Cloud comes with a powerful mediation engine that can transform and orchestrate API calls on the fly.

You can create your mediation sequences and apply them on the fly both on the way to the backend (In Flow) and back to the invoker (Out Flow):

API Cloud mediation sequences

API Cloud’s mediation engine is built on industry-fastest enterprise service bus (ESB) engine and supports amazing variety of mediators that you can use as building blocks for your sequences:

WSO2 Developer Studio can then be used to build your sequences:

Sample mediator sequence

And then you simply upload the sequences to the gateway and select which of them you want used in your APIs.

There are a couple tutorials that we published to illustrate the process:

Using Property Mediator to turn YQL-based Yahoo Weather API into nice REST format:

This is the step-by-step tutorial if you want to follow along:

And here is another one on turning a SOAP backend into a proper JSON REST frontend API.

Here’s the full list of mediators supported and links to detailed documentation:




Core Call Invoke a service in non blocking synchronous manner


Inserts a reference to a sequence


Drops a message


Enriches a message


Sets or remove properties associated with the message


Logs a message



Filters a message using XPath, if-else kind of logic

Validate Validates XML messages against a specified schema.


Filters messages using XPath, switch logic

Conditional Router

Implements complex routing rules (Header based routing, content based routing and other rules)



Performs XSLT transformations on the XML payload

FastXSLT Performs XSLT transformations on the message stream


Modifies and rewrites URLs or URL fragments

XQuery Performs XQuery transformation


Sets or removes SOAP headers

Fault (also called Makefault)

Create SOAP Faults

PayloadFactory Transforms or replaces message content in between the client and the backend server



Evaluates messages based on whether the same message came to the ESB

ForEach Splits a message into a number of different messages by finding matching elements in an XPath expression of the original message.


Clones a message


Splits a message


Combines a message


Blocks web services calls


Executes a set of mediators transactionally


Writes data to database


Retrieves information from database


Evaluates user actions against a XACML policy



Creates and executes a custom mediator


Executes a mediator written in Scripting language

Start your free API Cloud trial now!


Recent Posts

Most Popular Posts