On the specific application page, the subscriptions an application has are displayed, including the API credentials (either API Key or Client ID and Secret). You can use the revela button () to show the credentials for this application and API. Also the authentication type ("Auth Type") is displayed, which is important when deciding on how to access the API programmatically.

Application Name

In the second section you may change the friendly name of the Application. Please note that the friendly name of the application is only used inside the API Portal for making it easier to identify a client application. It does not have any impact whatsoever on the logic behind; for that, the application ID is used.

In contrast to the friendly name, the application ID can not be changed. The ID is additionally also unique over the entire API Portal installation. It is not possible for two different developers/users to create an applications with identical application IDs.


For a discussion of Application Owners, please see the page on application ownership.

Why Applications?

After signing up and logging in to this API Portal, you will want to subscribe to an API. In order to do that, the API Portal forces you to create an "Application" which serves as the consumer, or client, of the API. The "Application" is the entity you tie a subscription to, and not to your user.

How to use an API

Let us look at the following diagram which shows how the intended use of an API which is published within an API Portal looks like:

  • As a developer ("DEV" in the diagram), I visit the API Portal (I log in, I look around,...) and find the API which I want to use for the Application ("APP" in the diagram) I am currently developing.
  • Inside the API Portal, I register my application (using the applications page), so that the API Portal knows my application. It just needs an ID and a name of your application, nothing more.
  • After registrering your application, you can subscribe to an API for this application.
  • The API Portal will generate credentials (API Keys, OAuth Client ID/Secret) for your application, which you in turn use in your APP to actually access the API, via the API Gateway.

This enables the API Portal to create an abstract notion of applications inside the API Portal, and does not tie the subscriptions directly to the developer.