Release 10.5

Custom Runtime Policies API Providers can now invoke any external services, which can act as a runtime policy as part of the policy enforcement and thus can support custom runtime policies. Custom policies can be included in the stages such as, Identify and Access or Payload processing stages, or Routing stage. AWS Lambda functions also can be considered for custom policies.

Team work Support Team work support is to provide access control based on team-specific privileges in the deployments where multiple teams work on a single API Gateway instance. Assets of type API, Application, Package, Plan would be team-specific in such deployments and deployments where teams is not applicable, this can be switched off.

API First API-first is an approach where the design and development of an API comes before the implementation. API Gateway can now cater provider-complaint specification that can be used to register API first in API Gateway as part of API-first approach.

Externalization of configurations Inter-component configurations and cluster configurations are available at different locations causing maintainability and operational overhead. A new centralized configuration management is introduced in this version where configuration of API Gateway, Kibana, and filebeat connections to Elasticsearch and API Gateway, Elasticsearch and Terracotta cluster configurations for clustering is supported.

Command Central integration API Gateway integration with Command Central is enhanced for managing API Gateway instances through Command Central for Logs, Ports, Licensing, and Clustering configuration. The same is supported now through Command Central templates as well.

Change ownership of Assets Ownership of API and Application type assets can be transferred to a different user and can be implemented with Approval flow if desired. This would help to overcome the unavailability of specific data in the case where the current owner is not available in the system.

Governed API development APIs provided by CentraSite are considered read-only if a CentraSite destination is configured. If there is no CentraSite destination there is no connection to CentraSite and therefore no read-only restriction needs to be enforced. Scopes and policies can still be updated in API Gateway.