GraphQL shopifyPaymentsAccount.payouts returns fewer payouts than REST

Technical Q&A
,
1

We have problem with a customer where the REST API (admin/api/2026-07/shopify_payments/payouts.json) returns all payouts (32 in total) while a the following GraphQL query just returns 20 and does not have next pages.


 query businessEntities {
  businessEntities {
    primary
    shopifyPaymentsAccount {
      payouts(first: 50, sortKey: ISSUED_AT) {
        nodes { id issuedAt transactionType status net { amount } }
        pageInfo { hasNextPage endCursor }
      }
    }
  }
}

The customer has two business entities. But only one has Shopify Payments enabled. There seems to be a cutoff at 2026-06-15 for this merchant.

Here are two request IDs.

REST x-request-id
fd49c452-5552-4633-a0be-3628d4118689-1783602464
GraphQL x-request-id
2b416458-3e58-4b34-9635-4980eb82857d-1783605076

Querying the GraphQL API directly with an missing payout ID does not return anything.

query GetPayoutById {
  shopifyPaymentsAccount {
    payouts(first: 250,  query: "id:158560223567") {
        nodes {
            id
            issuedAt,
            legacyResourceId 
        }
    }
  }
}

But querying balance transactions returns the transactions belonging to that payout.

Are we missing something obvious?

2

Hi @twendt, I think the 2026-06-15 cutoff is the clue. That’s around when merchants started being moved to business entities, so the GraphQL businessEntities { shopifyPaymentsAccount { payouts } } query is only showing payouts for that specific entity. REST isn’t entity-scoped, which is probably why it returns all 32.

Since first: 50 comes back with 20 and hasNextPage: false, it doesn’t look like a pagination issue.

I would try two things:

  • Loop through all businessEntities and combine the payouts from each one.
  • Compare that with the top-level shopifyPaymentsAccount { payouts }.

If the older payouts still don’t show up, it feels more like a GraphQL limitation than an issue with your query. In that case, REST is probably the best option for historical payouts, and it’s worth reporting to Shopify with the request IDs.

Good Luck!

3

Hi @HamidEjaz, unfortunately the other entity does not have any payouts :confused:.

{
    "data": {
        "businessEntities": [
            {
                "id": "gid://shopify/BusinessEntity/<redacted>",
                "primary": true,
                "legalEntityId": "<redacted>",
                "displayName": "<redacted> – Entität",
                "archived": false,
                "shopifyPaymentsAccount": {
                    "payouts": {
                        "nodes": [
                            {
                                // oldest payout
                            },
                            {
                                // more payouts
                            }
                        ],
                        "pageInfo": {
                            "hasNextPage": false,
                        }
                    }
                }
            },
            {
                "id": "gid://shopify/BusinessEntity/<redacted>",
                "primary": false,
                "legalEntityId": null,
                "displayName": "<redacted> - entity",
                "archived": true,
                "shopifyPaymentsAccount": null
            }
        ]
    }
}

Could the "archived": true be a clue?

4

Hey @twendt ,
From what you’ve described, it doesn’t sound like you’re missing anything obvious.

If the REST endpoint consistently returns all 32 payouts while the GraphQL payouts connection only returns 20 with hasNextPage: false, and you also can’t retrieve the missing payouts by querying their IDs directly, that suggests the GraphQL API may not be exposing the full payouts history for that Shopify Payments account.

The fact that the related balance transactions are still accessible makes it even more interesting, as it suggests the underlying data exists but isn’t being returned through the payouts connection.

One thing I’d check is whether the missing payouts all belong to the same Shopify Payments account and whether they share any common characteristics (such as being created before a specific date a particular status or a migration event). If they do that could help narrow down whether this is an API limitation or a platform issue.

Otherwise with the request IDs you’ve provided, this seems like something Shopify Support or the API team would likely need to investigate.

Thank You !

5

@twendt yeah, archived: true is almost certainly it. when a business entity gets archived, its Shopify Payments account drops out of the normal businessEntities traversal, so those pre-cutoff payouts sit on the archived entity and just dont show in your query.

to pull them, query that archived entity’s shopifyPaymentsAccount { payouts } directly by its id (the gid://shopify/BusinessEntity/... you already have in the response). if archived accounts are filtered from the API entirely, REST stays the route for the historical ones.

6

One thing I’d test before leaning too hard on the archived-entity explanation: in your businessEntities response, the archived entity’s shopifyPaymentsAccount already comes back as null. That suggests there may not be a separate account object to query by ID there either, since GraphQL usually returns null when there’s nothing to resolve rather than “look somewhere else”. I could be wrong though, so I’d verify that assumption before chasing it.

A cheaper diagnostic might be the top-level query instead of going through businessEntities:

shopifyPaymentsAccount {
payouts(first: 50, sortKey: ISSUED_AT) {
nodes {
id
businessEntity { id }
}
pageInfo {
hasNextPage
}
}
}

If businessEntity is exposed on ShopifyPaymentsPayout, that would tell you whether the missing payouts belong to a different entity without having to query each one separately. If the top-level connection still stops at 20 with hasNextPage: false, I’d be leaning toward a GraphQL/API issue rather than an entity-scoping issue, especially since REST is clearly returning all 32 with the same merchant.