API Platform 4.3.5.0

We encountered a situation in which access tokens could be created for an API that was not deployed to any environment. This has been resolved, and now access tokens may only be created for apps linked to deployed APIs.

We fixed a front-end bug that caused an interceptor not displayed in the flow to be executed.

The feature of automatic health checks every 15 minutes on Settings  Health Checks was discontinued and has been removed from the front. For automatic monitoring and alerts based on API performance, see our solution Sensedia Flexible Actions.

When a plan was deleted, a success message was displayed along with an undue error message. The error message has been removed.

In some releases, it was not possible to configure the String Match Condition interceptor in the response flow, only in the request flow; this, because the interceptor was dragged into the flow, but the configuration window was not opening. The window is now opening normally and the interceptor is working as it should.

We solved cases in which, when removing an interceptor from the flow, a second interceptor was being improperly removed as well.

Calls with revoked tokens were returning HTTP error code 403 (Forbidden). We set the return to 401 (Unauthorized).

We weren’t validating Special Unicode characters in the path fields of resources/operations.

The gateway was not making explicit use of keep-alive (persistent connection) implemented in the backend for HTTP requests.

We fixed an error in some scenarios that prevented the creation of an API with the field Context) set to Teams.

Releases 4.3.x.x of the API Gateway only supported the HTTP protocol in versions 1.1 and 2.0. This created a backward compatibility issue for some customers and we have now expanded support for HTTP 0.9 and 1.0 as well.

In some scenarios, an API that had been deleted continued to appear on the front, even though it was inaccessible.

The list of users on Security  Users had a broken layout when displaying a user with a long login name.

When using the Internal API Call interceptor, the user can keep the parameters of the original request or add new parameters to the internal request. We verified and corrected this undue behaviour: when a user added manual parameters and then chose to keep the parameters of the original request, the parameters that had been entered manually were still sent.

[Adaptive Governance] We adjusted an undue behaviour of the Workflows feature of Adaptive Governance. If the user included a requirement that there can’t be a certain interceptor in the API’s flow in order for it to be saved in a certain stage, this was not preventing an API containing that interceptor from being saved.

[Connectors] We adjusted the alert message displayed when removing a connector; the layout was broken if the connector’s name was too long.

[Connectors] When a new revision was saved for an API that had a resource from connector, the feature was unset and the link with the connector was lost.