If the gateway configuration is correct, you will get a success message:

Image Removed

Use the drop-down list to define which user group can browse the API and the corresponding plan. This affects the view in the API Management itself as well as in the API Developer Portal:

• Organization Members (default): All members of the organization. The PAS user must be listed in one of the Identity Management groups API-Management-Users, API-Management-Administrators or API-Management-Developer-Portal-Users.
• API Management Users: Any PAS user listed in Identity Management groups API-Management-Users or API-Management-Administrators.
• API Developer Portal Visitors: Any PAS user listed in Identity Management group API-Management-Developer-Portal-Users and any user who visits the API Developer Portal, whether logged in or not.

For detailed information about the visibility concept, visit page The Concepts of API Management.

Testing of API configurations is only possible with REST APIs that are coming with an OpenAPI Specification.

Before the client is registered with the runtime gateway, it is not possible to make requests to backend APIs on behalf of that client.

For more information about the functions of the Swagger UI, go to the Swagger homepage.

For security reasons, you need to confirm the deletion.

The user gets a corresponding notification in the API Developer Portal.

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.

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

From PAS 22.1 all API Management users can create new organizations. In earlier versions, only users with role Administrator had been able to create organizations.

Once a plan is locked, it cannot be revised anymore. However, you can still create a new version of this plan.

Only locked plans can be used by APIs in the organization. See Locking a Plan for more information.

Please disable the TLS check if you are using Scheer PAS 21.1 or a newer version, because all PAS components are running behind a proxy server.

An IP Blocklist policy overrides an IP Allowlist policy.

It is strongly recommended to enable this option.

For detailed explanations about Cross-Origin Resource Sharing (CORS) visit the official Mozilla documentation.

Make sure that this option is true if you want to use this policy for authentication.

In the default setup the gateway runs behind a proxy. In the default scenario there is no need to add the header X-Real-IP in the custom header field IP Address HTTP Header.

Adding or removing policies does not enrich the Open API documentation. You need to adjust your documentation manually.

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.

You can forward the X-API-Key to the service using the API Key policy. However, you cannot define your own value for the X-API-Key, since the gateway uses the key to identify the clients.

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.