Cloud Blog

Category Archives: API Cloud

Download SDKs for Your APIs

WSO2 API Cloud now automatically generates and allows API subscribers and publishers to download Software Development Kits (SDKs) for any of the published APIs. SDKs are a great benefit for developers because they provide native programming libraries that give natural access to the APIs within the application code.

SDKs are available both in the Developer Portal (aka API Store) and Publisher.

Developer Portal

Inside the Developer Portal, subscribers simply need to browse to the API they need and click the SDK tab:


Within the Publisher UI, simply open the API for editing, and then click Edit Source on the first step of the editing wizard:

You can then use the Generate Server menu to get a stub for the server-side implementation of the API:

Or Generate Client for the client-side SDK:


We have upgraded WSO2 API Cloud to the new version that contains this feature and it is available to all API Cloud users at no extra cost and with no additional configuration required.

Check it out and let us know what you think.

Swapping version and context in API URLs

By default, APIs published in WSO2 API Cloud get URLs like http://{base-gateway-URL}/{API context}/{API version}/{API resources and parameters}. For example, if the custom URL that you assigned to your gateway is, you might get something like

But what if you want to place the version number first and have something like instead? This is trivial too. Simply type {version}/stats (or whatever your API context is) instead of just stats as the context on the first step of API creation:

And you can remove the version number altogether by selecting the Make this the Default Version checkbox on the 3rd step of API creation:

WSO2 API Cloud is a powerful API management platform that allows you to easily create the exact API program you need!

Change in internal username format

I have a quick announcement to make today. After a recent update of WSO2 Cloud, the internal representation of usernames changed and we no longer replace the @ sign with a dot in them.

With that change, your fully qualified username now looks like email@organization_domain. For example, if my email is and my organization domain in WSO2 Cloud is wso2cloud my fully qualified username would be

As you know, in most cases, you simply log into WSO2 Cloud with your email address. This is not changing in any way.

However, there are a few cases in which the internal, fully qualified login comes into the picture:

As I already mentioned, nothing changes for regular cloud login process: you simply keep using your email address there. The change only applies to the 5 advanced scenarios listed above.

Let us know if you have any questions or concerns.

Separating Development, Test, and Production

API programs typically have multiple teams involved: developers, quality assurance, acceptance testing, operations, and so on. Let us talk about the possible approaches to separating WSO2 API Cloud environments in order to give these teams the access they need while preventing them from interfering with each other’s work.

There are two main approaches that we see our customers take:

A. Setting up isolated API Cloud organizations,

B. Segregating API visibility within one organization.

Let’s look into these in detail.

Isolated API Cloud organizations

Separate API environments by provisioning separate organizations

Use this approach if you want to give your teams (for example, Developers and QC) full autonomy and reduce the risk of one team accidentally interfering with the work of another.

  1. You simply purchase separate WSO2 API Cloud subscriptions for the environments that you need. To create these extra organizations in WSO2 Cloud, click the Organization menu (in the 9-dot menu in the top-right corner) and click the Add Organization button.
  2. Upgrade each of the organizations,
  3. Invite team members to the organizations that they need.


  • You can use different subscription levels for different organizations. For example, you might need the Large subscription plan for Production but pick Starter for the Developer organization in order to optimize costs.
  • One can be a member of multiple organizations. In that case, they will be prompted to choose their organization at login.
  • You can use Export / Import functionality to move APIs between the environments.

Segregate API visibility within one organization

Separate APIs by assigning roles and setting API visibility

Choose this option if you want to fit the implementation within one subscription and are planning to assign team members to proper roles and ensure proper permissions set for each API.

  1. Create the roles that your organization has such as Developers, QA, Operations,
  2. Assign these roles to your team members,
  3. When publishing APIs, you set visibility to these roles: for example, if there is a new version of an API that is in testing, maybe only QC sees it.

In that scenario, all team members will be sharing the same WSO2 Cloud organization but the APIs and API versions that they see will depend on their role membership.

If you need any help from WSO2 on deciding which option is right for you, simply click the Support menu and ask for assistance.


Trace API calls and responses

To effectively troubleshoot APIs you need to know how your calls get transmitted to the backend and what the backend sends back. We have made this easy with the new gateway log access and tracing mediators. Here’s how.

1. Open for editing the API that you want to trace,

2. Go to step 2 (Implement),

3. Click the Enable Message Mediation checkbox and then select the debug_ sequences from the dropdowns for all 3 flows below it as shown in the picture:


4. Click the Next: Manage button at the bottom of the screen,

5. Click Save & Publish at the bottom of the last step of the editing wizard.

6. Open the live log by clicking the Configure / Admin Dashboard menu, and then clicking Log Analyzer / Live Log Viewer in Admin Dashboard’s left-hand menu pane.

Admin Dashboard log viewer

7. Now invoke the API (for example, in the API Store‘s API Console for that API).

8. You will see detailed information on the API request and response in the log:


9. When you are done troubleshooting, disable the message mediation that you enabled in step 3.

Try it in API Cloud today!

Throttle APIs by IP address, headers, parameters, and JWT claims

We have rolled out Advanced Throttling policies and you can now easily add rate- and bandwidth-limiting based on various parameters including IP address, HTTP headers, query parameters, and JWT claims.

For example, supposed I have an API for phone number verification created as described in our tutorial.

The API accepts 2 parameters: PhoneNumber and LicenseKey. LicenseKey 0 is a demo key so I would like to limit its use: if subscriber supplies 0 as LicenseKey I want to only allow 1 call per minute. For any other key, I will allow 1000 calls.

Here’s how I can set this up in API Cloud:

We will first start by defining the new throttling policy:

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

2. In the Admin Dashboard’s left-hand menu pane, click Throttling Policies / Advanced Throttling,

3. Click the Add Tier button at the top:


4. Give the new policy a name (I called it ‘ThrottleFreeLicense‘) and set the default limits (I set it to 1000 calls per 1 minute):


5. Now scroll down to the Conditional Groups section and edit the condition.

Policies can have multiple conditional groups but, in our case, we just need one because we only want to set LicenseKey = 0 as the special case.

You can optionally give it a name (such as ‘LicenseKey 0 gets 1 req/min’) and then select which kind of condition you want to include: IP address, HTTP header, query parameter, or JWT claim.

We will pick Query Param Condition, turn it ON, and then set Param Name to LicenseKey and Param Value to 0.


Click the Add button to get the condition added.

6. Now scroll further down and specify the limits when the condition above is met. In my case, when LicenseKey = 0, I want to only one request per minute allowed:


7. Finally, click the Save button to update the policy.

Now we need to assign this new policy to our API:

8. Back in API Cloud’s Publisher, open your API for editing,

9. Go to the third step of API editing (3. Manage).

10. In Advanced Throttling Policies, select Apply to API and select your policy (in my case ThrottleFreeLicense) from the drop-down list:


11. Click the Save & Publish button to make the change take effect.

Note: new policies take effect immediately. If you are modifying an existing policy, your changes will likely take about 15 minutes to take effect due to API caching.

Now you can give it a try.

12. Go to API Store and invoke the API either from the API Console tab or a curl command or any other client. You will see that the first invocation with LicenseKey = 0 succeeds while the immediate next one fails:

$ curl -X GET --header 'Accept: text/xml' --header 'Authorization: Bearer ca115527-25a7-3bba-879a-xxxxxxxxxxxx' ''

<?xml version="1.0" encoding="utf-8"?>
<PhoneReturn xmlns:xsd="" xmlns:xsi="" xmlns="">
<Company>Toll Free</Company>
<Use>Assigned to a code holder for normal use.</Use>

$ curl -X GET --header 'Accept: text/xml' --header 'Authorization: Bearer ca115527-25a7-3bba-879a-xxxxxxxxxxxx' ''

<amt:fault xmlns:amt=""><amt:code>900800</amt:code><amt:message>Message throttled out</amt:message><amt:description>You have exceeded your quota</amt:description><amt:nextAccessTime>2017-Jan-05 17:14:00+0000 UTC</amt:nextAccessTime></amt:fault>$

Besides exact match conditions (like in my example above) you can also specify IP address ranges and regular expressions for HTTP headers and JWT token claims.

Advanced throttling is a powerful mechanism that allows you to fine tune rate limits and bandwidth based on various API call conditions.

Give it a try in API Cloud today!

Now available in Canada

We are happy to announce that Canada is now one of the gateway locations offered by WSO2 API Cloud.


Canada joins the happy family of other WSO2 Cloud locations that already include the US, EU (Ireland and Germany), Brazil, Singapore, Australia, Japan, South Korea, India, and China.

You can host your APIs in any of these locations or even have a multiregional deployment in which subscribers either get redirected automatically based on their geographic proximity or choose their gateway explicitly.

Alerts on API performance and subscriber behavior

Do you want to be alerted when your API is down? Or when one of your subscribers starts behaving suspiciously invoking the API from a different IP address or in an unusual pattern?

All of this is now easy with WSO2 API Cloud!

Alerts can be configured on two levels: publisher and organization administrator.

The following alerts are available:

You can follow the links above for details on how each of them works.

To configure alerts on the publisher level:

  1. In API Cloud’s left-hand menu, click Manage Alert Types,
  2. Select the alerts that you want to receive,
  3. Specify the email addresses (press Enter after typing each address),
  4. Click Save:


To configure alerts on the organization admin level:

  1. In API Cloud’s Configure menu, click Admin Dashboard,
  2. In Admin Portal’s left-hand menu, click Analytics / Manage Alert Types,
  3. Select the alerts that you want to receive,
  4. Specify the recipient email addresses,
  5. Click Save:


New API Cloud Reports

We have significantly expanded off-the-shelf reports available in API Cloud:

Statistics tab in the Publisher interface now has 16 reports including both new and revamped old ones:

  • Reports now have a nice date picker and give the ability to compare behavior between API versions: for example, you can see whether API performance improved or degraded with the rollout of the new version,
  • API Latency report shows where exactly your API processing time is spent: authentication, call transformation, backend response, or throttling,
  • API Usage Across Geolocations helps identify your global API consumption trends so you can fine-tune your global sales and marketing, or geographic locations of your API gateways,
  • API Usage Across User Agents shows which platforms are being used to invoke the APIs so you can ensure that your documentation, sales, and marketing are in line with your subscribers’ needs,
  • Created APIs over Time helps you see how your project is evolving,
  • Developer Signups and Subscriptions Created over Time reports help see the dynamics of new subscriber acquisition.

Watch the video above for details and try the new reports in API Cloud today!


Recent Posts

Most Popular Posts