Dynamic Route Rewrite

The Dynamic Route Rewrite tool provides a runtime-based URL routing and rewriting functionality.

You can define flexible rules that control how incoming requests are processed and where they are directed. The routing logic can adapt to authentication state, environment (development, test, or production), or configuration context without requiring application-level changes.

Users access applications through clean and consistent URLs, while internal systems remain hidden behind a managed routing layer.

Routing rule conventions

Each routing rule defines how an incoming request is matched and where it is redirected. A rule consists of the following:

  • Incoming Path Pattern: the request pattern you want to intercept

  • Rewrite Path: the destination path to which the request should be rewritten

These elements operate together at runtime to provide controlled, configurable request handling.

Incoming Path Pattern

The Incoming Path Pattern specifies which URLs are matched. You can include parameters, wildcards, and optional segments to cover a wide range of path structures.

Convention Explanation Before (incoming URL) After (matched pattern) Example use case

:param

Matches exactly one path segment. The value is stored as a named parameter.

http://www.example.com/user/123

/user/:id

http://www.example.com/user/:id → handled by /user/:id

*wildcard

Matches one or more path segments, including slashes.

http://www.example.com/files/images/2025/logo.png

/files/*path

http://www.example.com/files/*path → handled by /files/*path

{}

Marks an optional path segment. The enclosed segment may appear or not.

http://www.example.com/users/123/delete

/users{/:id}/delete

http://www.example.com/users{/:id}/delete → matches both /users/delete and /users/:id/delete

Rewrite Path

After a path is matched, the rewrite path determines the target destination. You can reuse captured parameters or wildcards and include fixed query strings.

Convention Explanation Before (incoming URL) After (rewritten URL) Example use case

:param reuse

Inserts parameter values captured from the incoming pattern.

http://www.example.com/user/123

http://www.example.com/profile/123

http://www.example.com/user/:id → rewritten to http://www.example.com/profile/:id

*wildcard reuse

Inserts full path segments captured by a wildcard.

http://www.example.com/files/images/2025/logo.png

http://www.example.com/assets/images/2025/logo.png

http://www.example.com/files/*path → rewritten to http://www.example.com/assets/*path

Fixed query parameters

Adds constant query parameters. Path variables cannot populate query values.

http://www.example.com/user/123

http://www.example.com/user/123/get?type=1

http://www.example.com/user/:id → rewritten to http://www.example.com/user/:id/get?type=1
Certain system-critical routes beginning with /api, /cockpit, or /launchpad cannot be redefined. These paths are reserved to protect essential platform functions.

HTTP method scope

You can limit each routing rule to specific HTTP methods to control when it applies. Select individual methods or choose ALL to include every type. This allows you to separate routing for read and write operations, for example, when applying rewrites only to GET requests while letting POST or PUT calls reach back-end endpoints unchanged. Defining the method scope helps ensure routing rules trigger only where operationally intended.

Routing modes

You can configure routing to operate in one of the following modes: Always Rewrite or Auth-based Rewrite.

Always Rewrite

In Always Rewrite mode, all matching requests are rewritten according to the rule, regardless of user authentication. Use this mode for general restructuring or rebranding of URLs, such as redirecting http://www.example.com/oldapp → http://www.example.com/NewApp.

Auth-based Rewrite

Auth-based Rewrite lets you define routing behavior that depends on user authentication. You can configure separate rewrite paths for authenticated and unauthenticated users.

For example:

You can leave a rewrite path blank if no rewrite is needed for that condition. This mode ensures that users are routed to the correct destinations automatically, based on their access state.

Proxy and remote systems

You can optionally enable proxying to forward requests to another system instead of performing a local rewrite. When proxying is enabled, the routing layer passes the request to a back-end target while keeping the same visible domain. This allows you to direct traffic without exposing internal URLs.

You can select one of the following proxy options:

  • Remote System: Select a predefined back end configured in the Cockpit via the Remote Systems tool.

  • URL: Enter a full URL manually for the destination system.

Related topics