Release Notes for Red Hat 3scale API Management 2.7 On-premises

Red Hat 3scale API Management 2.7

Document intended for use with Red Hat 3scale API Management 2.7

Red Hat Customer Content Services


This document informs users about the latest and Technology Preview features, as well as resolved issues, associated documentation, and known issues in Red Hat 3scale API Management 2.7


This document is intended for use with Red Hat 3scale API Management 2.7 and related patch releases.

Chapter 1. Red Hat 3scale API Management 2.7.1 - Patch release

This document is intended for use with Red Hat 3scale API Management 2.7.1 On-premises.

1.1. Resolved issues

  • When modifying an existing application plan to disable a method on the backend level, it works as expected, with no error messages (JIRA #4013).
  • 3scale toolbox efficiently recognizes commands (JIRA #4009).
  • Improved performance of APIcast when using backend paths and you configure a second routing policy (JIRA #4016).
  • Now, policies remain visible while dragging to reorder (JIRA #4017).

Chapter 2. Red Hat 3scale API Management 2.7

This document is intended for use with Red Hat 3scale API Management 2.7 On-premises.

2.1. New features

2.1.1. Major features

  • Introducing a new way to manage your APIs: APIs as a Product (JIRA #1714), with the following advantages:

    • Separate internal APIs, Backends, from customer-facing APIs, Products.
    • Expose any number of Backends as one Product. You can perform your first steps with products and backends following the indications of the Getting started guide.
    • Re-use any Backend in any Product with different service-level agreements.
    • Simplify customer access to multiple Backends, by using a single set of credentials.
  • APIcast policy to configure Camel policy extensions (JIRA #2696).
  • Extended 3scale operators to enable upgrades from 2.6 to 2.7 under an OpenShift 4 installation. (JIRA #2378).

2.1.2. Minor features

2.2. Technology Preview features

  • High Availability (HA) and Evaluation (Eval) OpenShift templates (JIRA #1168).
  • 3scale operator for capabilities: It allows using custom resources to define 3scale tenants, APIs, plans, limits, metrics and other definitions to set them into a 3scale installation (JIRA #1798).

2.3. Resolved issues

  • The range of the characters allowed in client_ID and secret has been extended (JIRA #1451).
  • Fixed incorrect errors shown in developer accounts, under the Users and Invitations tabs (JIRA #1142).
  • Now APIcast works as expected when using the OPENTRACING_FORWARD_HEADER environment variable (JIRA #1660).
  • Improved APIcast logs regarding permission errors on the NGINX directory (JIRA #1912).
  • When adding a second URL address to the APIcast URL Rewriting policy, the Admin Portal displays consistent information with the configuration history (JIRA #1924).
  • After removal of custom policy from APIcast, the policy chain shows the remaining items (JIRA #3229).
  • Enhanced usability of the Configuration section of policies for cases when an API is updated with an invalid policy (JIRA #3396).
  • Resolved routing policy issues with the URL Rewrite policy when changing the URI (JIRA #3239).
  • Corrected message when calling a disabled method (JIRA #3330).
  • Now when you copy an API using the toolbox, the target API contains the same set of mapping rules as the source API (JIRA #3356).
  • Mapping rules are now matched when there are spaces in the URL path (JIRA #3468).
  • Reviewed functionality of the Update & Testing Staging environment button, by keeping a consistent behavior regarding existing policies (JIRA #3596).

2.4. Known issues

  • When you modify an existing application plan to disable a method on the backend level, an Internal Error (500 HTTP) message is displayed (JIRA #4013).
  • 3scale toolbox partially compatible with the new APIs as a Product feature (JIRA #3502).
  • Zync creates routes that are partly compliant with DNS rules (JIRA #2932).
  • When you change the OIDC Authorization Flow in 3scale, Zync does not update the Red Hat Single Sign-On (RH-SSO) clients of 3scale applications (JIRA #3025). To work around this issue, you have these alternatives:

    • For existing applications, update 3scale application such as a change in the description: This will trigger an update that will modify the RH-SSO client for the application.
    • Create a new application: This will create a new RH-SSO client with the correct authorization flows.
  • ProxyRule removes trailing slashes (JIRA #3872).
  • After reordering policies, the Update Policy Chain button stops working (JIRA #3941). To work around this issue, there are two alternatives:

    • Change the configuration of a policy; for instance enable or disable it.
    • Remove and re-create the policy.
  • Changes made for OIDC Authorization Flow settings in the Admin Portal cannot be saved. To work around this issue, use the OIDC Configuration Update endpoint in 3scale Account Management API (JIRA #4162).

2.5. Documentation

Supported configurations

Security updates

Upgrade Guide

  • Check the procedures to upgrade your 3scale installation from 2.6 to 2.7, for deployments based in templates and operators.

Changes in documentation

2.6. Changes in 3scale

This section lists the deprecated features and future changes for 3scale 2.7.

2.6.1. Deprecated features

  • Compatibility with OpenAPI Specification 1.2, formerly known as Swagger 1.2, is deprecated in this release. API specifications using this version will not be supported in future releases of 3scale.
  • Following the announcement in 3scale 2.6, Adyen payment gateway is not supported from 3scale 2.7. The recommendation is to migrate to one of the fully supported payment gateways: Stripe or Braintree.

2.6.2. Future changes

  • Since February 2017 code plugins are not supported as an integration configuration setting for your APIs but this option is still appearing in the Admin Portal. For future releases, we plan to completely remove this setting from 3scale.
  • Currently, template-based installation is the supported way for APIcast self-managed deployments. For the next releases, the new APIcast self-managed operator will be available as the only supported mechanism for OpenShift 4 configurations.
  • Currently, when Proxy Update is used, it creates a new APIcast configuration version for the Staging environment with the updated settings. This will not be the case in future releases; users will need to use the new Proxy Config Promote endpoint for this purpose.

2.6.3. Additional resources

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.