ServiceCallout Ignoring Request Path – Always Using /

[Vamsi_Sk]

Hi everyone,

I'm facing an issue with a shared flow where I'm trying to capture a GET request and forward it to Apigee X using a ServiceCallout from Apigee Edge. Everything works when I test manually, but when triggered the ServiceCallout ends up sending the request only to the domain (/), completely ignoring the original path.

🔧 Setup:

1. AssignMessage to construct the outbound request:

   <AssignMessage name="AM-prepareForwardRequest"> <AssignTo createNew="false">forwardRequest</AssignTo> <Set> <Verb>GET</Verb> <Path>{request.path}</Path> </Set> </AssignMessage>

2. ServiceCallout:

   <ServiceCallout name="SC-sendToApigeeX"> <Request variable="forwardRequest"/> <Response>apigeeXResponse</Response> <HTTPTargetConnection> <URL>https://xyz.com{request.path}</URL> </HTTPTargetConnection> </ServiceCallout>

   In Trace:

   • request.path: Captured Correctly (/generic/test/v1/customer/...)

   • target.url:  Captured Correctly (https://xyz.com/generic/test/v1/customer/...)

   •  But: servicecallout.requesturi = /

      

      What I've Tried:

     • Verified request.path and request.uri are correct

     • Logging forwardRequest.url before the callout (it looks right)

     • Tried using full <URL> in AssignMessage (https://...{request.uri})

     • Also tried skipping forwardRequest and calling the full URL directly in the callout

     ---

     The Issue:

     Despite everything being set correctly, Apigee still sends the callout with:

     requesturi: /

     The backend gets only the domain, no path, resulting in 404s.

     ---

      Question:

     • Why is Apigee ignoring the request path or URI when using forwardRequest?

     • How can I ensure ServiceCallout honors the full request path and query string when using a dynamically constructed message?

     Any help, advice, or working examples would be greatly appreciated!

     Thanks in advance

[dchiesa1 · Accepted solution]

Hi

it's hard to see what's going on because you haven't formatted any of the configuration you're sharing.  There's a button ^ above in the editor bar that allows you to format the stuff you share. It makes it much easier for readers to understand what you're asking about. 

I did notice that you have an AssignMessage with something like

<AssignTo createNew='false'>forwardRequest</AssignTo>
...

If that's what you have, you are specifically asking AssignMessage to NOT create a new request variable.  With the name of the variable you're referencing there, I would think you would want createNew='true'.  ??

I believe what ServiceCallout does if you reference a request variable that does not yet exist... it CREATES the request variable.  And it sets a bunch of default things, which I guess includes a path of  /

Also

You do not need ServiceCallout to forward a request. That is the job of the TargetEndpoint.  Are you clear on that?  What is the reason you want to use ServiceCallout instead of just a TargetEndpoint  ?

good luck sorting this out! 

[Vamsi_Sk]

Thanks for the insights, @dchiesa1.

we were able to identify the root cause — the issue was due to using a raw https:// URL inside the ServiceCallout within a shared flow. Although the request.uri was correctly constructed, the call was defaulting to /, resulting in 404s from the backend.

The solution was to switch to using a TargetServer in the ServiceCallout,

Once we made this change, the request was forwarded correctly with the full path, and the integration with Apigee X started working as expected.

So Marking this as resolved — appreciate the support!