How does the gateway handle calls to unmapped routes?

Since April 28, 2025, it is possible to configure your APIs to accept only requests that exactly match the routes registered in the Manager.

Previously, the Gateway accepted additional paths after a mapped route and also allowed the routing of operations not registered in the API. This happened mainly in two scenarios:

Scenario 1: additional paths after a mapped route

With only the GET /checking-account route configured, a call to GET /checking-account/balance was also accepted and routed to the backend, even without the /balance route existing in the API.

Scenario 2: destination configured in the main flow (all/all)

When the destination was positioned in the API’s main flow (which applies to any method and any path, all/all), it was possible to access any backend operation, regardless of whether it was registered as an API route. In practice, the main flow worked as a "wildcard" route, forwarding any received request to the backend.

With blocking of unmapped routes enabled, in both scenarios requests that do not exactly match a registered route now return a 404 error (Not Found).

How can I enable blocking of unmapped routes in my APIs?

New customers already have blocking of unmapped routes enabled by default.

For existing customers, the default behavior remains the same, and blocking is enabled upon request to the Sensedia support team. Once enabled, requests that do not exactly match a registered route will return a 404 error.

Why is this feature important?

This new behavior increases the security and predictability of routing, being especially useful in scenarios with:

  • Compliance requirements;

  • Environments with multiple applications exposed by a single backend;

  • Risks of exposing administrative or private endpoints;

  • The need for stricter control over valid API paths.

Does this mean there was a vulnerability?

No. The default behavior is similar to other market gateways, such as AWS API Gateway’s {proxy+}. It was designed for scenarios with dynamic routes. The new feature simply provides an additional level of control, aligned with security best practices.

Does this change affect my existing APIs?

No. The default behavior of your APIs remains the same. The new configuration will only be applied upon request and does not impact already configured routes.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]