Map Custom or Legacy API Paths

AI Gateway recognizes and governs LLM API traffic by matching the request’s URL path against each provider’s known paths. If a client—a legacy agent, custom proxy, or new provider variant—sends requests to a nonstandard path (for example /openai/chat or /custom/path), AI Gateway treats that traffic as unknown: it logs it under the generic “Other” category and performs no content inspection, policy enforcement, or activity logging.

Path Mapping fixes this. It lets you define path aliases per gateway so traffic sent to an alternate path is identified as a supported LLM API and receives full AI Gateway governance—no client changes and no wait for a Netskope release to support a new path.

What Path Mapping does

A mapping rule does one or both of the following:

• Classifies the custom or legacy path your client sends (the source path) as a supported API path so AI Gateway can inspect, apply policy, and log that traffic.
• Optionally rewrites the path forwarded upstream (the target path) — use this only when the upstream provider requires a different path than the client sends.

Pass-through is the default and most common case: the original client path is forwarded upstream unchanged, and the mapping exists solely to classify and govern the traffic.

Common scenarios

Scenario	Example	What mapping does
A provider “compatible” variant uses its own base path	A new OpenAI-compatible provider serves at /cool-ai/v2/chat	Classifies the traffic as a supported API and forwards it unchanged
Your proxy runs behind AI Gateway	Your app calls /myproxy/complete, and your proxy already handles that path	Classifies the traffic; it doesn’t rewrite the request
A legacy client is hardcoded to an old or different path	An older agent calls /custom-gateway/v1/models/predictions, while the service behind AI Gateway expects a different upstream path	Classifies the traffic as the matching API and rewrites the outgoing path to what the upstream service expects — the rewritten path can differ from the original
Paths include a model name or deployment ID	Requests follow patterns like /bedrock/<model> or /openai/deployments/<deployment-name>/chat/completions	One wildcard mapping covers every model or deployment name instead of a row per value

How it works

Each gateway has its own mapping table, configured per provider in the AI Gateway admin UI. Add a row for every custom or legacy path you want AI Gateway to recognize.

Field	Required	Description
Source path	Yes	The path your client sends, for example /openai/chat.
API path	Yes	The standard API path AI Gateway should treat this traffic as, for example /v1/chat/completions. This must match one of the provider’s supported APIs — AI Gateway validates it and shows the valid choices if it doesn’t.
Target path	No	The path forwarded upstream to the provider. Defaults to the source path (no rewrite). Set this only when the upstream provider expects a different path — the target path can differ from the source and API paths.
Method	No	POST (default) or GET.

Using wildcards for paths with model names or IDs

Providers sometimes embed a model name, deployment name, or ID in the path. To cover every value without adding a row per model, use a single * in both the source path and the API path:

Source path	API path	Notes
/gen/*	/v1beta/models/*:generateContent	One row covers every model behind /gen/
/openai/deployments/*/chat/completions	/v1/chat/completions	One row covers every custom Azure OpenAI deployment name
/bedrock/*	/model/*/invoke	One row covers every Bedrock model

A few rules apply:

• Only one * is allowed per path.
• If the source path has a *, the API path must have one too (and vice versa).
• The value matched by * carries through unchanged to the API path (for classification) and the outgoing request.
• Rows without a * are treated as exact matches; exact matches are always checked before wildcard rules.
• Query strings on the original request are never part of the match — they are preserved and forwarded unchanged.

Adding mappings

To add a path mapping for an AI provider, follow the steps below.

1. Log in to the Netskope tenant UI and go to Settings > Security Cloud Platform > AI Gateway > AI Provider.

2. Find the provider you want to add a mapping for, click its … (options) menu, and select View.

   

3. In the provider panel, select the Path Mapping tab.

4. Click Add Path if the provider has no existing mappings, or Edit Path if it already has one or more.

   

5. Under Path #1, enter the values for the following parameters:

   

   • Source Path: The path your client actually sends. For example: /compatibility/v1/chat/completions.
   • API Path: Select the standard API path for this provider’s schema from the dropdown. Only paths already supported by that schema are listed.
   • Target Path (optional): Enter an upstream path only if the provider needs a path different from the source path. Leave this blank for pass-through (the default).
   • Methods: Select POST (default) or GET.

6. To map additional paths for the same provider, click + More Path and repeat step 5 for each one.

7. Click Save.

   

The new mapping is added to the provider’s path mapping list, and the Path Mapping count updates on the AI Provider page.

What doesn’t change

• Any unmapped path is still logged under “Other” and receives no inspection, policy enforcement, or activity logging—mapping adds coverage; it does not remove it.
• Mapping a path does not translate the request or response body between providers. The payload must already match the schema of the API you map to.
• Query strings on the original request are always preserved.