URL Rewrite on AIGatewayRoute api.

[aditya1036]

Description:

Currenlty URLRewrite feature is not available for AIGatewayRoute api , whereas in case of HTTP Route we can rewrite url.

For example -> Gateway receives call with http://:80/test and internally it points to /anthropic/v1/messages which external process can understand and perform its task.

Is there any way we can achieve this or AIGatewayRoute Api needs enhancement.

[Aditya7880900936]

Thanks for raising this.

From what I understand, AIGatewayRoute currently doesn’t expose URL rewrite semantics similar to HTTPRoute, which makes it harder to map user-facing paths to upstream provider-specific endpoints (e.g. /test → /anthropic/v1/messages).

Before jumping into implementation, it might be good to clarify:

• whether URL rewrite is intentionally omitted from AIGatewayRoute to keep the API minimal, or
• if aligning it closer to HTTPRoute semantics (e.g. path rewrite / prefix replacement) is an accepted direction.

I’d be happy to help explore possible approaches or draft a proposal if this is something the maintainers are open to.

[aditya1036]

Thanks for providing input .
I think your points makes sense , lets hear back from other maitainers.

[Aditya7880900936]

@zhaohuabing

[zhaohuabing]

It seems that the current design intentionally limits routing to header-based model selection on fixed paths (like /v1/chat/completions, /v1/embeddings, etc.), and hostnames are auto-rewritten to the selected backend’s host via the generated HTTPRouteFilter.

cc @envoyproxy/ai-gateway-maintainers, who have more insights on this than me.

[Aditya7880900936]

Thanks for the clarification, that makes sense.

Given that path-based routing and rewrites are intentionally constrained to keep the API surface minimal, I want to make sure I’m aligned before going further.

Would it be reasonable to explore one of these directions instead?

1. Explicitly documenting this design choice (fixed paths + header-based model selection) in the AIGatewayRoute docs, since it’s not obvious to users coming from HTTPRoute semantics.
2. Supporting a very narrow, opt-in form of path rewrite strictly for provider compatibility (e.g. mapping a user-facing alias to one of the fixed upstream paths), if that aligns with long-term goals.
3. Or confirming that this is intentionally out of scope so we can close the issue as “by design”.

Happy to help with docs, a proposal, or a small scoped PR—whatever is most useful.

[aditya1036]

Thanks @Aditya7880900936 and @zhaohuabing for inputs.
So then if its as per design according to you two, intentionally path rewrite is not implemented on AIGatewayRoute Api .
If everybody agrees we can document it and to avoid further confusion in future.

Can help in documention for this.

Thanks.

[Aditya7880900936]

Thanks everyone for the clarification.

Based on the discussion, it seems clear that:

• AIGatewayRoute intentionally does not support path-based routing or URL rewrite
• Routing is designed around fixed provider paths with header-based model selection
• This is a deliberate design choice to keep the API surface minimal and focused

To avoid future confusion for users coming from HTTPRoute semantics, I’m happy to:

• Add explicit documentation calling out this limitation and the rationale, or
• Submit a small docs PR clarifying “by design” behavior and recommended patterns

Let me know if that sounds good, and I can proceed with docs.