ServiceCallout Ignoring Request Path – Always Using /

Google Cloud Apigee
, ,
1

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.

:wrench: Setup:

  1. AssignMessage to construct the outbound request:

    forwardRequest GET {request.path}

  2. ServiceCallout:

    apigeeXResponse https://xyz.com{request.path}

    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 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

2

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!

1 Like
3

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!