Best approach in Apigee for routing multiple SOAP APIs from the same root URL based on a common SOAP attribute

Hi everyone,

I have multiple Apigee API proxies in the same environment. I am sharing only 2 examples here, but the actual requirement applies to around 71 SOAP APIs.

All of these APIs receive requests in a SOAP envelope, and each request contains one common attribute in the SOAP body that can be used for routing.

For example, I have APIs like:

  • customerdetails

  • accountdetails

Each API currently works with its own base path, such as:

  • /api/v1/customerdetails

  • /api/v1/accountdetails

But the business also wants all of them to be callable directly from the same domain root, for example:

https://apigee.mock.com/

The idea is:

  • if the SOAP attribute value is customerdetails, route to the customerdetails API

  • if the value is accountdetails, route to the accountdetails API

  • and similarly for many other APIs

The problem is that when I add:

<BasePath>/</BasePath>

to multiple proxies, deployment fails because / is already claimed by another proxy, which makes sense from a routing perspective.

Since this requirement applies to around 71 APIs, I want to understand the best architecture in Apigee for this kind of implementation.

My main concerns are:

  1. What is the best design approach for handling this at scale?

  2. Should I create a single dispatcher proxy on / and route internally based on the SOAP attribute?

  3. Should I use proxy chaining to forward from one root proxy to the existing proxies?

  4. Is it better to merge all logic into one proxy, or keep separate proxies and use one routing layer?

  5. Which approach is better from a performance, maintainability, and response time perspective?

I would really appreciate best-practice guidance from anyone who has implemented something similar in Apigee for a large number of SOAP APIs.

Thanks.

1 Like

Hi @Asjid_Tahir, thanks for the question. We’ve got this on our radar to ensure it gets the visibility it deserves. In the meantime, you might find these resources helpful while we wait for the community to weigh in:

:memo: Knowledge Hub

:play_button: Community TechTalks

We’ll keep an eye on this thread.

Hi @AlexET and all,

Thanks everyone. I got this working.

The approach that worked for me was:

  • creating a single root/dispatcher proxy on /

  • extracting the common SOAP routing attribute from the request body

  • using that value to route internally

  • forwarding the request to the existing child proxies through proxy chaining using LocalTargetConnection

So instead of assigning / to multiple proxies, only one dispatcher proxy owns /, and the actual APIs continue to use their own existing base paths.

This worked well and solved the deployment conflict cleanly. Sharing in case it helps someone facing the same issue.

4 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.