Page History

The API Documentation button and a button to download the API definition file are also available here.

The API Documentation button grants access to the Swagger UI where the user can test the API (refer to Testing APIs for further information).

On the details page of a Public API, users can find further information about the API such as an extended description and the public endpoint.

You can expose all forms of APIs in the Developer Portal:

Further below on the documentations page you can find the Swagger UI.

Use it to send test requests to the API. Enter test data and execute a request. For more information about the functions of the testing UI, refer to the Swagger pages.

Do not forget to click the Save button when you have finished.

Click to add a new item to a list, click to show/hide the list of items.

API Management sets the CORS headers in the following order:

1. CORS headers from the CORS policy have the highest priority.
2. Then, if no CORS policy has been defined, CORS headers from the API are used.
3. Then, if 1 and 2 are not the case, special headers for the integrated Swagger UI are used.

1. First of all you can consult our complete technical documentation.
   The documentation is divided into several guides:
   
   • an API Management User's Guide
     You can search this documentation using the search box on the left, in top of the content tree.
   • INSTALLATION for all modules
2. If you can't solve your problem with help of the documentation, you can file a ticket to our support team at support@scheer-pas.com.
   All mails to our support mailbox will open a ticket in our service desk.
   Optionally, you may use our service desk portal. There, you can manage your tickets and raise new support requests. Using the portal requires you to register your email address, which will not take much time.

3. To help you with your problem, our Support team needs some information on your software and environment. Please refer to Information to Include in a Support Request for more details on this.

API Contracts and API Keys

Only public APIs can be accessed by any consumer. The only way for a client to consume a private API is by using an API contract. An API contract is a link between a client and an API through a plan offered by that API.

API contracts can only be created between clients and published APIs which are offered through at least one plan. An API contract cannot be created between a client and a public API.

When an API contract is created, the system generates a unique API Key. This key is unique per client and the same for all contracts of this client. All requests made to the API by a client through the gateway must include this API Key. The API Key is used to create the runtime policy chain from the policies configured on the API, plan and client.

APIs in API Management represent real back-end APIs (Application Programming Interfaces). An API is also known as a service, meaning anything that can be invoked remotely by some sort of client. API Management provides a way to turn unmanaged (raw) back-end APIs into managed APIs by attaching policies to them.

Every managed API can be published as Public API or Private API or both:

• Public APIs are available to consumers without a key. Only policies defined on the API apply to public APIs.
• Private APIs are only accessible for known consumers, called clients. Every client has an individual key to access the API. Policies defined on the client, the selected plan in the contract and the API apply.

In API Management, users can create new APIs manually or easily import them from the API Catalog.

The client is the consumer of the API:

• The client consumes managed APIs offered through API Management.
• 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 creating a contract, an API-Key to invoke the API will be assigned.

Almost everything in the API Management data model exists in the context of an organization:

• An organization is a logical unit within API Management. This can be a company, department, etc.
• An organization is a container of other elements: plans, APIs, and clients are defined per organization.
• Every user must be associated with at least one organization to be able to manage elements in the application.
• API Management implements role-based access control for users. You can give organization members different roles to restrict the actions he is able to perform and the elements he can manage within the organization.
• Membership for each organization can be easily managed in the Organization tab.

A plan is a set of policies that defines the level of service API Management provides for an API.

• Plans enable users to define multiple different levels of service for their APIs.
• Plans specify the contract between a client and an API.
• It is common to define multiple plans with divergent configuration options for the same API.
  Example:
  An organization offers two plans for the same API: Plan A is more expensive than plan B, but it offers a higher level of API requests in a given (and configurable) period of time.

Policies are at the lowest level of the data model, but they are the most important concept: 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.
• You can define a policy chain, a defined order in which the policies will be applied to API requests.