Skip to content

MindSphere Gateway


MindSphere Gateway acts as gateway to the MindSphere cloud backend for web application clients, agents and edge applications, as well as all external and internal app backends and services. Web applications or web services integrated with MindSphere Gateway can be reached from the internet using the external gateway access. The routing has to be defined by every provider of apps or services using Gateway Registry. The identity management is integrated with gateway to support web application OAuth 2.0 authorization code flows and to exchange access tokens of interactive or active clients in cross-provider requests.


URL Schemes

In the following, the URL schemes of public URLs mapped to MindSphere Gateway are defined. Public URLs are callable from the internet. MindSphere Gateway routes requests to public URLs to registered internal IPs like your internal Cloud Foundry app route.

Curly brackets {} are used to define placeholders for mandatory URL parts and square brackets [ ] to define placeholders required only in defined specific cases.

Call to MindSphere Web Application

A web application hosted in MindSphere can be exposed at the gateway under the following hostname:



  • {tenant} identifies the tenant accessing the web application. It helps to direct the user to the IdP(s) available for that tenant and also allows creating tenant-specific bookmarks in the browser.
  • {webapp}[-{provider}] identifies the web application uniquely. MindSphere core web applications omit the provider part, while other web applications need to include this part to avoid name collisions and in order to keep the core namespace clean.
  • {region}[-{env}] identifies the data center region the request is issued to. The env part identifies the environment (e.g. preview) and is only appended for the preview environment.
  • [{path}] optional path parameters, to reach sub-content of the web application. The first path parameter needs to be different than /api to avoid conflicts with API routing.


  • a user of tenant abc loads content from the MindSphere fleetmanager web application in region eu1, production environment.
  • a user of tenant abc loads the index page from the fleetmanager web application of provider xyz in region eu1, production environment.
  • a user of tenant xyz loads an icon from the fleetmanager web application of provider xyz in region eu1, production environment.

Web Application Client Call to MindSphere API

The web application client calls MindSphere APIs under the same hostname that it was retrieved. The URL path parameter determines the target of the call.



  • {webAppHost} is according to the Call to MindSphere Web Application section.
  • {apiName}[-{apiProvider}] uniquely identifies the API. Core APIs omit the api-provider part for URL simplicity. Non-core APIs need to append the provider name of the API to avoid name collisions and keep the core namespace clean.
  • v{major} identifies the major version of the API.
  • {endpoint} identifies an endpoint of the API. Can be a nested path.


  • a user of tenant abc uses the MindSphere fleetmanager web application client in region eu1, to access the IoT core API v2, endpoint assets.
  • a user of tenant abc uses the MindSphere fleetmanager web application client in region eu1, to access the fleetmanager UI mashup (core) API v3, endpoint fleets.
  • a user of tenant abc uses the xyz fleetmanager web application client in region eu1, to access the xyz IoT Services v3, endpoint assets/46b55e6f.

Active Client Call to MindSphere API

Active clients are supposed to be running outside of a web browser. They don't require a tenant or web application identifier in the hostname. The target API is determined in the same way as for web application client calls, though.




  • a client calls region eu1, to access the IoT core API v3, endpoint assets.
  • a client calls region eu1, to access the Asset Management API v3, endpoint assets.

Device Agent Call to MindSphere agents or edge API

Device agents call MindSphere in the same way as general northbound clients, but use a different subdomain name.




  • an agent calls region eu1, production environment to access the the service API v3, endpoint serviceEndpoint.


The following restrictions are enforced when making requests to either your own registered applications or MindSphere APIs. These are only MindSphere Gateway limitations, individual MindSphere API endpoints' limitations may be stricter.

Option Value Description
Connection timeout 65 seconds timeout when forwarding request to a backend service. Connection is closed after this time by MindpShere Gateway
Parallel connection count 400 maximum number of simultaneous connections per MindSphere Gateway instance
Cache invalidation timeout 15 minutes MindSphere Gateway internal cache timeout (Invalidation of data loaded from dependent services such as Gateway Registry)
Session timeout 12 hours maximum lifetime of a user session. Users must re-login after this time
Session inactive timeout 30 minutes maximum lifetime of a session without user activity
Session cookie timeout infinite maximum lifetime of the session cookie
Access token expiration 30 minutes expiration time of an access token
Refresh token expiration 12 hours expiration time of a refresh token
Maximum request size 150 MB maximum size of a request that can be sent
Maximum file size 100 MB maximum size of files that can be attached to a request
Maximum header size 16 Kb maximum size of headers in a request



Though MindSphere Gateway applies security measures to protect web applications and services in the MindSphere backend, every web application and service in addition is responsible to apply authorization validations to ensure working access control.


MindSphere Gateway requires web applications to use the provided CSRF token mechanism, including a same origin check based on the origin http header.

Content-Security-Policies (CSP)

MindSphere Gateway applies a strict Content Security Policy header for web applications, which is not configurable for 3rd parties. All served resources must come from the application uri or the static content uri (static.{region}[-{env}]

A web application may employ the use of CSP by including one of the following HTTP headers in the response:

  • Content-Security-Policy
  • Content-Security-Policy-Report-Only

By default, MindSphere Gateway adds a CSP header for web applications:

Content-Security-Policy: default-src 'self'; style-src * 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src * data:;

parties. For more information about CSP please read the official specification from the W3C or the CSP documentation from MDN web docs.

Cache Control

MindSphere Gateway can use the specified Cache-Control header values of web applications for caching mechanisms in both requests and responses. The configuration value is the Cache-Control directive list that contains the cache configuration rules in complience with the Cache control header specification.

The default value for Cache-Control header:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

In case when the no-cache option is used Mindpshere Gateway will automatically add Pragma: no-cache and Expires: 0 headers.

Any questions left?

Ask the community

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