Bulk Query nested items is not possible

I’m trying to avoid hitting the Rate Limit by doing normal queries, so I decided to go and do a BulkGraphQL query.

In this example, I am trying to download all the orders for analysis.

The problem is that there are a lot of limitations with this GraphQL API.

  1. Maximum of 5 links
  2. Queries that contain a connection field within a list field are not currently supported.
{
    orders {
        edges {
            node {
                id
                refunds {
                    id
                    createdAt
                    refundLineItems {
                        edges {
                            node { id }
                        }
                    }
                }
                shippingLines {
                    edges {
                        node { id }
                    }
                }
            }
        }
    }
}

The first problem can be avoided, I would just have to query multiple times.

However, the second problem is constraining. I am incapable of getting the data within the “refunds” because it is considered a list within a list.

If I could request all refunds and do some mapping later, it would be great, but refunds is not a valid root query.

What is the recommendation for querying nested like this?

If I could request all refunds and do some mapping later, it would be great, but refunds is not a valid root query.

That’s exactly the approach I would take.

You can perform a separate Bulk Operation for the other nested resources.

Sounds like you’re using a lot of data. Are you doing some kind of analysis? Just curious on the use case.

It’s the approach you would take and I would take as well, but how could I get the refunds… There are no API for this?

Yes, the software is doing some market analysis for the shop.

I see, without subresource list support you cannot use the Bulk Operation API to retrieve non-root resources like refunds.

I guess the closest option you have is to use the Bulk Operation API to retrieve all order.refunds and then use the individual refund IDs against the Admin API and retrieve these subresources.

It will count toward your API limit, and introduce an n* operation, but at least you can get all of the data eventually.

Correct, as you can see it’s defeating the whole purpose of using the BulkAPI… now I have to loop slowly around all potential refunds by calling refund, which then is the same as not using the BulkAPI in the first place.

Do you work on the Shopify team? is there a way to make a feature request here?

I just stopped at refunds here, but it will be the same for all other sub list…

Nope! I’m also a Partner, but Shopify staff are very active on this board and take in this feedback as part of their API design.

Yea I can see how this is a shortcoming of the Bulk OP API. Either way it is a slow operation to read all of this data on larger accounts. But the good news is I think it would be outliers for an order to have enough refunds to qualify for pagination in the first place.

Since this is for reporting reasons, it might not need to be real time anyway. Just to play devils advocate.