FAQ

If you want to enable external users to consume your API, you need to publish it to the API Developer Portal.
Refer to Developer Portal in the API Management Guide.

How the user can access / consume your API depends on the API type. Refer to Subscribing to a Private API and to Consuming a Public API for details.

Instead of creating an API, you can import it from the PAS Administration. Refer to Importing APIs in the API Management Guide for a detailed step-by-step instruction.

Before you can publish your API, you need to finish its configuration. Refer to Configuring an API in the API Management Guide for an overview on all necessary configuration steps.

APIs represent real backend APIs (Application Programming Interfaces). An API is also known as a service, which offers a HTTP, REST or SOAP interface that can be invoked remotely by a client.

Scheer PAS API Management provides a way to turn unmanaged (raw) back-end APIs into managed APIs by attaching policies to them. Any policies configured on an API will be applied at runtime, regardless of the client and API contract.

An API has to be fully configured, including policies and implementation (and in case of public APIs including plans) to be published. If the API has been published to the gateway it can be consumed - in case of private APIs by clients.

Refer to APIs in the API Management Guide for details.

Scheer PAS API Management supports the creation and management of two different types of APIs: public APIs and private APIs.

A private API cannot be consumed by everyone: They require an API Key in order to be called. To consume a private API, a client and a contract must be created. Compared to a public API, private APIs require more complex configuration. But you can control the access to private APIs in a very fine-grained manner, you have insight into various metrics that can be displayed per client and you can map different access levels by assigning restricted usage plans to a private API.

Refer to API Types: Public vs. Private in the API Management Guide for more detailed information.

Scheer PAS API Management supports the creation and management of two different types of APIs: public APIs and private APIs.

A public API can be consumed by everyone (assuming no additional security policy has been set). It is also very easy to consume a public API: You just need to know its public endpoint. Clients do not need to register for a public API: Neither a client nor a contract are necessary. Compared to a private API, a public API requires less configuration.

Refer to API Types: Public vs. Private in the API Management Guide for more detailed information.

A client is the consumer of the API and is only required to use private APIs. Each client can consume multiple APIs within API Management. The relation between client and API is defined via a contract and a plan. As with an API or a plan, you can also add policies to a client.

When a client version is created, the system generates a unique API Key. This key is unique per client and the same for all contracts of this client version. All requests made to the API by a client through the gateway must include this API Key to identify the used client version.

Refer to Clients in the API Management Guide for more detailed information.

A contract is a link between a client and an API through a plan offered by that API. A contract is necessary if a client wants to consume a private API, it cannot be created between a client and a public API. API contracts can only be created between clients and published APIs which are offered through at least one plan.

Refer to Contracts in the API Management Guide for more detailed information.

An organization is a container of other elements: plans, APIs, and clients are defined in the organization. An organization contains and manages all elements used by a company, department, etc. within API Management.

Every user must be associated with at least one organization to be able to manage elements in the application. Scheer PAS API Management implements role-based access control for users. The organization membership of a user defines the actions he is able to perform and the elements he can manage within the organization. Before any other actions can be taken, an organization must exist. All other operations take place within the context of an organization.

Refer to Organizations in the API Management Guide for more details.

A policy is a rule or a set of rules API Management uses to manage access to your APIs. Policies are applied to all API requests and represent a unit of work applied at runtime to the request by API Management.

Policies are applied through a policy chain: when a request to an API is made, API Management creates a chain of policies to be applied to that request. The policy chain is applied to the request in a fixed order: Client policies are applied first, then policies added to plans, and finally policies added to the API itself.

Refer to Policies in the API Management Guide for more details.

The API Developer Portal allows you to grant customer developers access to your APIs. In the Developer Portal, developers can sign up for APIs, access them, and try out APIs that you have enabled for them. The portal is designed to keep the discovery and use of APIs simple for the target group. 

Refer to Developer Portal in the API Management Guide for more details.

The visibility concept of API Management defines which user groups can find the APIs in the Developer Portal. The visibility resides on top of the permission system as another security layer. Visibilities are applicable to public APIs and plans for private APIs. Three different visibilities are available: Organization members (default), API Management users, and API Developer Portal users.

Refer to The Concepts of API Management in the API Management Guide for more details.

For xUML services that have been deployed from the Designer as a container, secured endpoints are created automatically. However, these services are only usable internally and are not exposed to users outside the company. You have access to these endpoints via the service details in the PAS Administration. Refer to Controlling Containerized xUML Services (Docker) or Controlling Containerized xUML Services (Kubernetes) depending on your PAS setup.

If you want to make the APIs available to others, you can publish them via Scheer PAS API Management and restrict their usage with additional policies.
Refer to Exposing Designer Services via API Management in the API Management Guide for a detailed description.