Skip to content

Integrating API application to the UI application

A user can develop backend applications to support multiple UI applications. These backend applications are called API type applications. With these type of apps, the developer is empowered to re-use the functional logic in multiple applications. Also, multiple API applications (with a maximum of 5 apps) can be set as dependency to a UI application.

This guide describes the lifecycle of an API application and its integration to the UI application.

Deploy, Register and Test a Stand-Alone API application

It is required to create a stand-alone API application before adding dependencies.

The API type application can either be CF hosted or Self-Hosted. To create a CF application, refer Running a Cloud Foundry-Hosted Application, and for self-hosted application, refer Self-Hosted Application.

Differences between API and other application types

  1. The format for versioning of an API application is as follows:

- v\<major>.\<minor>.\<patch>-\<label(optional)>

- e.g. v1.0.0, v2.1.0-alpha

- Limits -- v[0-9].[0-99].[0-99] -\<label>

  1. For API apps, the "Configuration" fields are not applicable since there are no configurations available.

  2. API applications cannot be Mendix-based.

Testing the API application

To test the API application, you need to create a sample UI application and call the API of this application. This is the only way to access or the API type application. To call the API, the application needs to be first configured with the UI application. For more information refer Configuration of API application with UI application.

Configuration of API application with UI application

The developer of the UI application needs to configure the URL of the API application within the UI application's code.

The URL of API application is built when the application is registered. This URL can be fetched from the application details page of API application once its registered.

API type URL

Once the URL is fetched, it can be used within the code of the UI application to call the APIs of the respective API application.

To configure the application roles and scopes, the application needs to be added as dependency of API type application. For more information, refer API application dependency to standard application.

New versions and revisions of existing Applications

For API application, the version registration is handled differently. Unlike "Non-API" applications, API applications can have multiple versions registered at the same time. Revision is an update to the present version. "Revision" is for API versions whereas "Version" is for Standard Application.

There can be a maximum of 10 versions and 100 revisions/patches (upperlimit of format v9.99.99-\<tag>).

For API app, it is possible to register multiple versions, but not multiple revisions of the same version.

Creating New Versions

  1. In the "Dashboard" screen, click "Create New Version".
  2. Select the API application and select "New Version".
  3. Enter the new version by following the versioning format defined.
  4. Click "Clone".

Rules for API versions

  • Major version must be higher than selected version.
  • API version should start with \'v[0-9]\'.
  • Maximum length should be 30 characters.

Creating New Revisions

  1. In the "Dashboard" screen, click "Create New Version"
  2. Select the API application and select "Revision".
  3. Select "Revision"
  4. Enter the new revision following versioning format defined above.
  5. Click "Clone".

Rules for API revisions

  • Major version must be same as the selected version. The max version is filled automatically.
  • Minor version or patch must be incremental than the selected version.
  • Maximum length (of version string) should be 30 characters.

API application dependency to standard application

Once the API application is created successfully, it can be added to standard application as dependency. An API application can be a dependent of any type of application except itself.

Once the API app is added as a dependency, the flow of dependent "non-API" application will be dependent on API application. Dependency rules to be followed are as below:

  1. Standard Application cannot be registered until all dependent API's are registered.
  2. Standard Application cannot be uploaded until all dependent API's are uploaded.
  3. Standard Application cannot be assigned until all dependent API's are assigned.

Add API Dependency to Standard Applications

Dependencies can be added only if the application for which the dependency is being added, is not registered.

  1. In the Standard Application details page, access the API Dependency Tab.
  2. Click on "Add API Dependency". This opens the API applications list.
  3. Select the application-version which is to be added as dependency.
    • Upto 5 dependencies can be added to an application.
    • For each dependency application, only one version of an API app is allowed as a dependency.
  4. Once added, the list of dependencies are visible in the standard Application details page.

Third Party API roles

The API applications can be accessible to Standard applications only when the third party API roles are provided to the standard application.

To associate third party roles, proceed as follows:

  1. In "Developer Cockpit", access the "Authorization Management" tab and select "App roles".
  2. Select third party API roles.
  3. Click "Add API role".
  4. In the pop up, click the API role name. From the drop-down, select the role that you wish to associate with the app, along with the access level (admin/user).


  • User should add and configure the scopes to protect their own application endpoints.
  • Similar scopes can be updated for application in Developer Cockpit Authorization Management.
  • Mindgate will provide Oauth token based on the scopes provided in Developer Cockpit Authorization Management.

App Credentials

In case the "Non-API" app has a dependency on the API app, the app credentials are valid only for "Non-API" app. The API app will not be accessible via app-credentials.

Last update: January 22, 2024

Except where otherwise noted, content on this site is licensed under the Development License Agreement.