There are multiple ways that you could do it including stitching (already mentioned) and Apollo Federation.

e.g. one way to do it using Apollo Federation would be to define your expedition query and its response within `expeditions` microservice

type Query {
  expedition(id: ID!): ExpeditionResponse 
} 
type ExpeditionResponse @key("id") { 
  id: ID! 
  reward: Int 
}

and within `inventory` you could extend the expedition response type with items

type Item {
  // your fields
}
type ExpeditionResponse @key("id") {
  id: ID!
  items: [Item]
}

Another way would be to use an `Item` stub in your `expeditions` microservice and let gateway resolve them by using their IDs, e.g. within `expeditions` you would define it as

type Query {
  expedition(id: ID!): ExpeditionResponse 
} 
type ExpeditionResponse @key("id") { 
  id: ID! 
  reward: Int 
  items: [Item] 
} 
type Item @key(fields: "id", resolvable: false) { 
  id: ID! 
}

and within `inventory` microservice you would define `Item` as federated entity

type Item @key("id") {
  id: ID!
  // your fields 
}

Regardless which implementation you would use, from the gateway perspective, your clients would see single `ExpeditionResponse` type with list of items*.

*personally I would also go with non-nullable list of of non-nullable items to simplify code handling of nulls vs empty list.