Skip to main content
err:frontline:client:ambiguous_path
The API you called runs on Unkey and uses gateway policies. Its path could reach different handlers depending on how the reads it, so the gateway rejected it before it reached the app. You get 400 Bad Request. The gateway rejects:
  • Encoded dot segments, such as %2e%2e or ..;.
  • Double-encoded slashes or backslashes, such as %252F or %255C.
  • %2F (an encoded /) or %5C (an encoded \), when a policy matches paths with a regex.
Example response
Browsers get the same error as an HTML page.

​
If you’re calling an API hosted on Unkey

Send the path without encoded dot segments or double encoding. If a value such as an ID contains / and the API still rejects it, send it in a query parameter, a header, or the request body instead of the path.

​
If you own this API

Frameworks disagree on these paths. Some resolve %2e%2e as .. and others treat it as a literal name. Some treat %2F as a path separator and others keep it inside the segment. An app that decodes the path twice turns %252F into /. The gateway can’t tell which handler your app will pick, so it rejects these paths instead of risking a policy being skipped. A single %2F or %5C is only rejected when an enabled policy matches paths with a regex, because only a regex like [^/]+ can be bypassed by changing how many segments a path has. Prefix and exact policies accept it. The check runs only for apps with enabled policies other than logging.

​
How to fix

  1. If you need / in path values, use prefix or exact path matches instead of regex.
  2. Otherwise, move values that can contain / or \ out of the path, into a query parameter, header, or body, and update your clients.
Last modified on November 6, 2026