Setting up a route

Routes tab → add an Upstream (name + base URL) → enter a path prefix, pick the upstream and (optionally) a credential → Add route.

• Strip prefix (on by default): /app/my-service/foo forwards upstream as /foo — the prefix is just a local label. Turn it off only if the upstream expects that prefix in its own path.
• The full local endpoint is shown ready to paste into a client config.
• Routes can be disabled without deleting them.
• Prefixes must be unique, and /mcp is reserved for funnel endpoints.
• Upstream base URLs must be https except on localhost — the access token goes to every request forwarded there.

How the credential is sent#

By default the token goes out as Authorization: Bearer <token>. For upstreams that want it elsewhere, each credential on a route has a placement, a name, and a value prefix:

Query-string placements have been removed. A URL is recorded by the upstream's access log, by every intermediary between here and it, by browser history, and in the Referer of anything the response loads — none of which RavensPort can redact. An upstream that accepts its credential only as ?access_token= cannot be used through RavensPort.

A route inherited from an earlier version with a query placement is not served at all: the config builder drops the whole route rather than forward it with that credential missing, and the activity log names it as SKIPPED. Change the entry to a header or body field to bring the route back.

• The value prefix is literal text before the token — Bearer including the trailing space. Leave it empty for a bare token.
• A caller-supplied header or field of the same name is replaced, never duplicated, so the upstream never sees two candidate credentials.
• Body injection applies to JSON objects and application/x-www-form-urlencoded bodies up to 1 MB, including chunked and streamed ones. Anything larger or in another content type is forwarded untouched and the activity log says why.
• Header names the proxy owns are rejected: Host, Content-Length, Transfer-Encoding, Connection, Upgrade.

Zero, one, or several credentials per route#

Select a route in the grid to open its editor — the route's own proxy key sits at the top, the credentials below it. Add credential appends another entry; Remove drops one. Every entry has its own credential, placement, name, and prefix, so a route can carry any combination:

• Entries are independent: two different credentials side by side, or the same credential in two places (some APIs want the token in a header for auth and echoed in the body for audit). OAuth2 and API-key credentials mix freely on one route.
• Adding a credential to a route prefills from that credential's default placement, so an X-Api-Key credential arrives already described as one.
• A route with no credential still forwards, and still strips the caller's own Authorization header and cookies. Attaching nothing is not a licence to relay whatever the caller sent — that guarantee holds on every route, and the route's own proxy key is still required.
• No two entries may write the same slot. Two credentials on one header or one body field would silently overwrite each other, so the pair is refused at the point of editing. Header names are compared case-insensitively (HTTP treats them that way); body field names are case-sensitive.
• A credential you delete stops being attached on the routes that referenced it — the other credentials on those routes keep working. The row shows ⚠ credential missing.
• If a request cannot carry a body placement (a GET, or a body this cannot parse), that entry is skipped and the header entries on the same route still arrive. The activity log names every credential that was attached and every one that was not.
• Routes created by older versions carry their single credential over unchanged on first load.

Edit this page on the wiki Request support · Report vulnerabilities privately