Glossary

The AMPLIFY platform is Axway’s cloud-based customer engagement and data integration platform. For example, this includes API management, app development, analytics, file and sync share, and integration. You must sign up on the AMPLIFY platform before you can use API Central Service.

The API catalog is the list of APIs that an API consumer is authorized to access. The API consumer only views the exposed API (methods and documentation) and not the internal details of the API proxy.
The APIs in the API catalog include the fully qualified URLs of the deployed API proxy methods so that the API consumer can invoke the URL. These URLs are sourced from the deployed API proxy. The API Catalog views in API Portal and API Manager are example API catalogs.

API Central Service is a cloud-based system for self-service API management, which provides a central and unified management layer across multiple environments and clouds. API Central Service enables you to register, virtualize, secure, and manage your APIs, client applications, and API consumers.

An API Central Service administrator manages APIs, client applications, runtimes, teams, and users in API Central Service. This administrator role is typically an operational user who has knowledge of what the APIs do and why clients need to access them.

API consumers are users of the APIs that are provided and managed by API providers. API consumers can be end users, client apps, app developers, or teams. For example, the API consumers for a credit card company could be retailers that enable their customers to make payments by credit card. API consumer users are managed by API administrators in API Central Service.

An API developer is an API Central Service user who registers APIs, applies policies, and exposes these APIs in client applications that they create. The API developer is is responsible for the lifecycle of the API (for example, registration, publication, and deprecation).

An API provider is an enterprise that exposes APIs to their consumers (for example, a credit card company providing payment services to customers). API consumers can include both internal development teams and external customers and partners.
API providers are Axway customers that subscribe to the AMPLIFY platform. A single API provider is a tenant of the AMPLIFY platform and represented by a single organization. The API provider’s users (for example, API developers registering APIs) are platform users in that organization and are managed by on the AMPLIFY platform by the platform administrator.

An API proxy is a facade or stand-in for an API that is designed for use by API consumers, and access to the API is managed using the API proxy. API consumers send requests to the API proxy, policies are applied, and the request is routed to the API.
API Central Service enables you to create proxies for REST APIs by importing Swagger definitions and applying reusable policies to manage API consumption.
The API Proxies page in API Central Service displays registered API proxies and associated documentation. APIs are represented in Swagger 2.0 format, and you can manage multiple API proxy revisions. Client app developers can browse and tag API proxies for classification and searching.

This is the version of the API proxy that is generated by API Central Service (for example, revision 1, 2, or 3). New API proxy revisions typically result from changes in the API implementation (for example, new method added and Swagger re-imported), or changes in the API proxy (for exmple, different policies applied).

This is the read-only version of the back-end API registered in API Central Service, and is used to display the API version in the API catalog (for example, version 1, 2, or 3). This is a documentation-only field, which is read from the Swagger version, and is not updated by API Central Service.

The client registry is the API Central Service repository of API consumers, partners, teams, and client applications that consume the REST APIs. The client registry also contains the authentication credentials of the client applications, and authorization and quota policies defined at the team and application level.

An API Central Service logical instance is a business-level partition of API Central Service that is owned by a specific tenant (for example, corresponding to a specific customer business unit or geography, such as Acme Widgets USA or Gran Banco EMEA). The API Central Service administrator for a specific API Central Service instance grants access to specific tenant users.

API proxies are deployed from API Central Service to microgateways running in a specific runtime environment (for example, development or production). Promoting an API proxy from development through to production is in effect deploying the API proxy from API Central Service to the API microgateway in each runtime environment.

An AMPLIFY platform organization defines a logical group of AMPLIFY platform tenant users (for example, an Acme Widgets or Gran Banco organization). You must sign up on the AMPLIFY Platform before you can use API Central Service. See also Tenant.

API Central Service provides reusable basic API governance policies that are applied to all API proxies and built into the underlying API microgateway. For example, these include authentication, authorization, and rate limiting—throttling (to protect from overload) and quota (for monetization).
You can extend these basic API governance policies with reusable custom policies developed using Policy Studio and executed by the policy engine, which is part of the API Central Service runtime.

API proxy and policy configuration are pushed from the API Central Service governance layer to specific runtimes implemented as microgateways to handle processing of requests. Configuration is cached locally at the runtime for performance and reliability, so runtimes can operate independently of governance in case of connection outage. Supported runtime environments include AMPLIFY platform public cloud, virtual private cloud, customer managed cloud, or on-premise (container-based deployment).

The API Central Service runtime administrator is responsible for provisioning specific runtime group environments. Each API Central Service logical instance has at least one runtime administrator who can create runtime groups and add or remove other users as runtime administrators.

A runtime group is a collection of API Central Service instances where the same API proxies are deployed (for example, Dublin development group or Phoenix production group) for a specific tenant organization. The runtime group is implemented as a group of microgateways running the same API proxies for performance, scalability and high availability. API proxies and the client registry can also be federated across multiple runtime groups to be distributed and partitioned in multiple environments.

Each runtime group has at least one runtime group administrator. By default, the creator of the group is admin. Runtime group admins can create/update/delete runtime groups and add/remove users and grant/revoke admin and deploy permissions.

An API Central Service team defines a logical group of users (for example, a project team developing APIs, a specifc business unit, or an external partner consuming APIs). A user can be a member of multiple teams, but works with API Central Service in the context of a single team at any one time. Users, applications, API proxies, and runtime groups are associated with teams, and access is based on team membership. For example, an API developer can access the API proxies associated with the teams they are a member of, but not the API proxies of other teams.

An API Central Service tenant is an Axway customer who owns one or more dedicated API Central Service logical instances, and who pays by subscription (for example, Acme Widgets Inc.). See also Organization.

An API proxy exposes an API version. If multiple API versions are made available to API consumers, there are multiple API proxies—one for each API version. Client applications explicitly route to an API proxy that virtualizes the API version that the application wants to invoke.
Each API proxy has a specific version routing that client applications use to route their request to the correct API proxy (for example, /myapi/v1 and /myapi/v2 for URL path version routing). The version routing is unique to an API proxy, and no two API proxies can have the same version routing. See also API version.