Cloud Blog

Category Archives: API Cloud

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.

Recorded Webinar: Hybrid API Management and On-Premises API Gateways

If you missed the webinar about the on-premises gateway feature that we recently added to WSO2 API Cloud there is now a recording available!

Hybrid API management lets you get the best of both worlds:

  • The agility and low total cost of ownership of SaaS,
  • The high security, compliance, and performance of local API gateways.

In the webinar, I demoed the feature and answered lots of questions that attendees had. Enjoy the recording!

Going Hybrid! On-Premises API Gateways

Today is a huge step forward for us: we are rolling out on-premises API gateways.

With this feature, you can have the best of both worlds:

  • API Cloud hosts the web user interfaces (both for API publishing and for API subscribers), configuration, and analytics,
  • You download and install in your network the API Gateway component, which then gets its configuration from the cloud and starts serving the APIs and proxying the calls.

There are multiple advantages to this deployment model:

  • Performance: you can put your API gateway close to your backend services and API subscribers thus avoiding the costly extra hops to the cloud and back,
  • Security and Compliance: API call and payload data does not leave your network and this keeps your security and compliance officers happy,
  • Connectivity: your API gateway is running locally so you do not have to set up VPN or another way of exposing your backend to the internet,
  • Low Total Cost of Ownership (TCO): Most of the infrastructure is run and maintained by WSO2 for you.

The feature is available at no extra cost to all customers of API Cloud’s Large and Extra-Large subscriptions.

To get started:

1. Log into WSO2 API Cloud and click the Get On-Premises Gateway menu:

2. Follow our On-Premises API Gateway documentation or contact our cloud team to get help with the setup.

WSO2 API Cloud in 2017

2017 was a great year for WSO2 (we are now the world’s 8th largest open-source company!), API Cloud, and our customers.

Thanks to the feedback that you provided, we have added numerous great capabilities to our cloud service. Below are just the highlights and the key new features and improvements that we have rolled out last year.

New API Design Capabilities

Advanced throttling: you can now set rate limits not just by the subscription plan but by multiple other criteria including IP addresses, headers, parameters, and JWT claims.

Native WebSocket support – now WebSocket APIs are first-class citizens in API Cloud.

Ability to have multiple backend endpoints per API and route calls on the fly based on your rules.

API Subscriber Benefits

Automated SDK generation for your APIs – API subscribers can download automatically generated SDKs for the programming language of their choice and get going developing their applications quicker.

Even more branding capabilities: you can now set your look, feel, and content not just to the Developer Portal (API Store), but also to the emails that the system sends, to the Publisher UI, and even the error messages.

Mutual SSL as a supported authentication mechanism between API clients and the gateway (and obviously between the gateway and the backend).

Cloud-Service Specific Functionality

Live log access and ability to trace the requests and their transformation for easier troubleshooting and API debugging.

Custom roles and ability to limit visibility and OAuth scopes based on them for better security design and management.

Integration with external Identity Providers and identity stores, including single sign-on for the web UIs,  ability to hook up end-user stores, and SAML integration.

Deeper integration with AWS: not only you can now have API Cloud’s gateway in any AWS datacenter of choice, you can also get API Cloud simply added to your AWS bill to simplify your accounting and vendor management.

Infrastructure Improvements

Full data encryption inside API Cloud: both in transit and at rest.

Separation between production and non-production environments for clean dev-test-production lifecycle.

Comprehensive set of our own APIs that allow you to use API Cloud programmatically and integrate it into whatever custom user interfaces and tools you develop.


Thank you for being a WSO2 customer and helping us innovate and advance our services!

Built-In Page Help

Happy New Year!

We have added a quick enhancement that should make API management easier for you in 2018. Now, all API Cloud pages have a context-sensitive Help button on the right-hand side:

Clicking the button, shows you the help pages that we think are most relevant to your current page:

Give the new tips a try and let us know if any useful information is missing on any of the pages!



Multiple features now included with API Cloud tiers

Today we are happy to announce that we are now bundling multiple API Cloud features (some new, some previously existing but requiring extra fees) into existing API Cloud subscription tiers at no extra cost!

Here are the features that we are adding:

Getting Traction and higher:

Medium and higher:

There are also some very exciting features in the works for Large and Extra-Large tiers so stay tuned for more announcements in January.

For our current paying customers affected by the change we will be happy to use whatever approach is the most beneficial for the customer:

  • If you are currently using a feature that is now a part of a higher tier than yours, we will let you continue to use it at your current level.
  • If you are paying for a feature that is becoming free at your tier (for example, VPN or VPC Peering at Medium and higher) we will stop charging you for the feature.

We keep looking to how we can provide more value to our customers. If you have any questions or ideas on how we can further evolve our offering please let us know.


Add WSO2 API Cloud to your AWS Bill

WSO2 API Cloud has a long history of integration and partnership with Amazon Web Services. Boasting 5-star rating, the service has for a long time offered comprehensive API management capabilities that go well beyond just API gateway and include analytics, real-time alerts, user management, full-featured developer portal, API monetization, integration with identity providers and user directories, and powerful on-the-fly transformation engine.

In 2016 we added the capability to have your WSO2 API Cloud gateway in any AWS datacenter of your choice and VPC peering between your AWS VPC and WSO2 API Cloud.

Today we are happy to announce that you can purchase WSO2 API Cloud right within your AWS account and simply have the service added to your Amazon bill.

If you are an existing AWS customer and want to turn your services into managed APIs and launch a full-scale API program, simply go to the API Cloud page in AWS marketplace and pick the tier that works best for your needs.

APIs to control your API Management

In WSO2 API Cloud, everything you do through the web user interface can also be done programmatically via APIs. Detailed API reference can be found in the API Cloud’s Product APIs documentation.

Today I will show you just a quick example on how you can use Publisher’s RESTful APIs to get a list of APIs published (for all other operations you would use a similar approach and simply other REST resources from the API reference).

1. Register client

1.1. Obtain your organization-qualified ID

The first thing we need to do is register our API client and obtain the consumer ID and consumer secret values.

The most important piece of information that you need for that is your domain-qualified ID in WSO2 Cloud. This is your email address @ your Organization Key. You can find your Organization Key by clicking Organization on the 9-dot menu at the top right of the cloud interface.

For example, on the screenshot below, my Organization Key is wso2dmitry2639:

With my email address, this gives me the qualified ID of

1.2. Create registration json

This is just a payload.json file that would have the ID that you have just obtained. In my case that would be:

  "callbackUrl": "",
  "clientName": "rest_api_publisher",
  "tokenScope": "Production",
  "owner": "",
  "grantType": "password refresh_token",
  "saasApp": true

Save that text file as payload.json.

1.3. Encode your credentials

Now you need to take the qualified ID from step 1.1, add a colon (:), add your password and do Base 64 encoding for that string. For example, if my password was P@ssw0rd, I would have needed to encode and that would have given me: ZG1pdHJ5QHdzbzIuY29tQHdzbzJkbWl0cnkyNjM5OlBAc3N3MHJk

1.4. Register the client

Now you can just run this curl command in the folder that has your payload.json from step 1.2:
curl -X POST -H "Authorization: BasicZG1pdHJ5QHdzbzIuY29tQHdzbzJkbWl0cnkyNjM5OlBAc3N3MHJk" -H "Content-Type: application/json" -d @payload.json

This will give you an output like:

         \"grant_types\":\"password refresh_token\",

This response has everything we need: clientId is your consumer key and clientSecret is your consumer secret.

2. Obtain OAuth token

2.1 Encode consumer key and consumer secret

Now we need to take the clientId and clientSecret values, put a colon between them, and base 64 encode that string. In my case, I need to encode O7buGR5fMVMuNBFF:A3mYNQjHDsXX_T1.

When I do that, I get TzdidUdSNWZNVk11TkJGRjpBM21ZTlFqSERzWFhfVDE=

2.2 Find your scope

In the documentation page for the method you want to call, find which scope it needs. I just want to use Retrieve/Search API and this method requires apim:api_view scope.

2.3 Request the token

Now you have everything you need to get the OAuth token. Simply run this (with your own ID, encoded keys, and scope):

curl -k -d "grant_type=password&" -H "Authorization: BasicTzdidUdSNWZNVk11TkJGRjpBM21ZTlFqSERzWFhfVDE="

You then get a response like that:


access_token is the OAuth key you can use for your calls.

3. Use the APIs

Now you can just take that access token and use it with the API call that you pick from the reference page. In my case, for the token that I got, to get a list of all APIs, I would call:

curl -k -H "Authorization: Bearer 89c12aab-6f0e-3c3b-8409-d186670ec73c"

I then get a response like:

  "description":"Country data API",

For my tutorial, I picked just one simple call to list the APIs. Full reference has dozens of methods that you can use to completely bypass our user interfaces and perform any API management operations programmatically.

Check out API Cloud’s Product APIs documentation and let us know what you think.

Put your SOAP to REST

API management is about selectively, securely, and conveniently exposing internal functionality to the outside world. Quite often external consumption model and internal representation of APIs do not match and this is when API gateways shine efficiently translating one representation into the other on the fly.

Exposing SOAP web-services of internal enterprise systems as lightweight external REST APIs is a very frequent case of that. Here’s what it looks like:

  1. External REST API is called. Parameters are typically passed as parts of the URL path, query parameters, headers, or JSON payload. Authentication typically happens via OAuth2.
  2. API gateway receives the call, checks OAuth keys, enforces various policies such as throttling and scopes, records the call for analytics and monetization purposes, and creates a SOAP call with the new payload based on expected format and parameters, then passes the call to the backend.
  3. The backend would typically use some other form of authentication such as basic or digest authentication, mutual SSL, and IP whitelisting.
  4. When the backend responds, the gateway would do another transformation of the response to the format that the web or mobile client expects – typically JSON.

WSO2 API Cloud makes this process easy and efficient. See our documentation for details:

See also this blog post by Shenavi:

Multiple CNAME records within a single gateway

Your APIs can work with multiple backends and route calls to them based on different headers, REST resources, or even parameter values. Today we are expanding this functionality to routing based on multiple gateway URLs so the same API can, for example, serve production, development, and test environments picking the appropriate one based on the URL used for the invocation.

Typically, all your APIs share the same base URL of the gateway that you can set to a particular custom URL of your choice such as

Also, starting with the Medium plan, API Cloud allows you to have multiple gateways. This is typically used by API publishers who want to have separate API gateways for different regions (for example,,,

That same functionality can now be used within the same physical gateway to provide different URLs for different backend environments such as,, and In that case, you can assign them all to the same API gateway and then use the Dynamic Endpoint type to route the calls to the corresponding backend environments based on the URL used by the caller.


Recent Posts

Most Popular Posts