Design pattern for API with type identifier that determines what downstream services to call

I have an endpoint, let's call it "GetPersonInfo". GetPersonInfo is given a few parameters but one of them is "PersonType". Based on this PersonType, multiple downstream services are called. Some of these services could be shared between PersonType's but that is not a guarantee.

For example GetPersonInfo(...) #1: PersonType = "Adult"

When GetPersonInfo is called for Adult, the API endpoint would need to make two downstream calls and populate the payload model with results: "GetPersonName()" and "GetFavoriteAlcoholicBeverage()"

For example GetPersonInfo(...) #2: PersonType = "Child"

When GetPersonInfo is called for Child, the api endpoint would need to make two downstream calls and populate the payload model with results: "GetPersonName()" and "GetFavoriteToy()"

For example GetPersonInfo(...) #3: PersonType = "NamelessPerson"

When GetPersonInfo is called for NamelessPerson, the api endpoint would need to make one downstream call: "GetPersonIdNumber()"

Each of these calls would be populating the same model PersonInfo but all of the fields are nullable in case the downstream call wasn't required for that person type.

Is there a pattern where I can achieve this without duplicating the common downstream calls in every single logic implementation for getting the person info by PersonType.

Below is the initial call

public PersonInfo getPersonInfo(int id, PersonType personType) {
        // logic here based on personType to call necessary downstreams and populate person info model
    }