Federated Graph orchestration of multitenant apis for the same subgraph

Hello. I am new to graphql and I think federated graph can help with my project. I wanted to confirm this is possible.

I am simplifying things greatly but here is the gist of it.

I have no central system that hosts all data but each system has their own api. I want to bring all these under a common API. I want to have 1 federated graph that will define some number of subgraphs and be able to conditionally route to the correct subsystem.

I want to bring all these under one federated graph such that they all start using a common query syntax. By doing this I could use the same front end against 1 graph and the graph will figure out the correct api conditionally based on calling front end.

For example I have 3 stores who each have their own product api (3 different product apis) that return roughly the same data (product name, description etc.).

Each app will pass as a parameter “app-id” and with that my hope is the federate graph can determine which product api to route to. From there it will transform the response back into the defined common graph response format. app-id1 would resolve against api1, app-id2 would resolve against api2, etc.

I also need to support the use case where it may require different number of end points depending on app api to fetch all the requested fields. To clarify, app1 may need to hit different end points to resolve product name. app-id3 would resolve against a combination of api3 and api4 for fields

I need to be able to resolve N number of different source systems because cannot know over time how many product apis are out there.

Can federated graph achieve this? And if so what mechanism does this?

Just guessing at ways

1 subgraph per api however this sounds like it prevents me from having the same query from the storefront work.

1 subgraph for all apis but the resolver has to do a ton of work to conditionally fetch for each?

Less ideal but an alternative, is we define the common schema and each store front runs their own instance of a federated graph. This is less ideal but I can imagine it greatly reduces the conditional logic