Using stripe.Client, List methods no longer expose pagination related properties

[chanioxaris]

Describe the bug

For the List methods, when using the new stripe.Client instead of the now-deprecated resource-specific clients (e.g., customer.Client{}), the SDK no longer appears to expose certain pagination related properties, such as has_more

To Reproduce

Now, doesn't seem to be a way to access the pagination related properties but only iterate over the results

params := &stripe.CustomerListParams{
	ListParams: stripe.ListParams{
		Limit:  stripe.Int64(20),
		Single: true, // fetch single page and not iterate
	},
}
for customer, err := range sc.V1Customers.List(context.TODO(), params) {
	// handle err
	// handle customer
}

// there is currently no way to access the 'has_more' property

Expected behavior

I would expect a way to have access to the pagination related properties, such as has_more

Code snippets

Previously, it was possible to access the pagination related properties via the Meta() method

params := &stripe.CustomerListParams{
	ListParams: stripe.ListParams{
		Limit: stripe.Int64(20),
	},
}
i := sc.Customers.List(params)
for _, customer := range i.CustomerList().Data {
	// handle customer
}
if err := i.Err(); err != nil {
	// handle err
}

// there used to be a way to access the 'has_more' property
print(i.Meta().HasMore)

OS

macOS

Go version

Go 1.25.0

stripe-go version

v82.4.0

API version

2025-07-30.basil

Additional context

No response

[mbroshi-stripe]

👋 Hi @chanioxaris ! Thanks for bring up this issue! You are right that there is currently no way to access HasMore through stripe.Client. Can you tell me more about your use case and how you are you using that property?

[chanioxaris]

Hey @mbroshi-stripe, as part of our company pricing, we fetch and preview the invoices for each customer in our Dashboard. So we need a way to let the UI know whether there is more data to fetch or not, a pretty straightforward pagination use case

[mbroshi-stripe]

Yep, makes a lot of sense! Thanks for added context! We are working on a fix for this and I'll circle back if we need any additional info. In the meantime, although it is marked as deprecated, a workaround is to use the old client.API pattern.

[mbroshi-stripe]

@chanioxaris Just to make sure we implement what you are looking for, did you mean to call HasMore after completing iteration in your example? At that point it will always be false. If you could, could you update your example with something closer to how you intend to use the feature?

[chanioxaris]

@mbroshi-stripe if I’m understanding your question correctly, yes after the iteration I’d like to somehow get the value of the top level has_more property so I can return it to the caller along with the fetched data.

I tried accessing it via LastResponse.RawJSON, but unfortunately that property only contains the resource related data and not the full API response.

[mbroshi-stripe]

Did you want to collect all values in-memory and pass that to the caller, or just the first page of values? Your example as it stands will iterate through all values after which HasMore will be false (by definition). Under the hood, Next() automatically re-paginates. If you want to just return the first page, you would need to access i.CustomerList().Data, which updates as you iterate.

If you can provide an updated example of what you were doing and/or pseudocode of you would like to do, that would be helpful.

[chanioxaris]

@mbroshi-stripe oh yeah, you’re right, my bad! I’ve updated my example to correctly demonstrate the previous behavior and only access the 'first page' of the data

[mbroshi-stripe]

AFAICT, for your described use case, I think you need to do something like:

limit := 10
it := customer.List(&stripe.CustomerListParams{
	ListParams: stripe.ListParams{
		Limit: stripe.Int64(int64(limit)),
	},
})
for {
	if err := it.Err(); err != nil {
		return err
	}
	page := it.CustomerList().Data
	hasMore := it.Meta().HasMore
	doSomething(page, hasMore)
	if !hasMore {
		break
	}
	for range limit {
		it.Next() // advances through to end of iterator
	}
	it.Next() // fetch next page
}

Is this what you're trying to accomplish? We're still noodling a little on design, but we'll have to make a new method like ListWithPage to support this, and hopefully we can make manual pagination a little more ergonomic.

[chanioxaris]

@mbroshi-stripe what we’re doing right now looks something like this, we’re using the deprecated client’s List method. We’re not blocked at the moment, but I assume we will be once we have to upgrade to a newer major SDK version, since the deprecated client initialization will likely be removed

import (
	"context"

	"github.com/stripe/stripe-go/v82"
	"github.com/stripe/stripe-go/v82/customer"
)

func ListStripeCustomers(ctx context.Context, limit int) ([]*stripe.Customer, bool, error) {
	params := &stripe.CustomerListParams{
		ListParams: stripe.ListParams{
			Context: ctx,
			Limit:   stripe.Int64(int64(limit)),
		},
	}

	iter := customer.Client{...}.List(params)
	if err := iter.Err(); err != nil {
		return nil, false, iter.Err()
	}
	
	return iter.CustomerList().Data, iter.Meta().HasMore, nil
}

[mbroshi-stripe]

👋 Hi @chanioxaris ! Thanks for providing an example--that was very helpful! FWIW, I think what you need for your use case is to include the StartingAfter parameter as well, otherwise you'll only fetch the first page. So, something like:

func ListStripeCustomers(ctx context.Context, limit int, customerID *string) ([]*stripe.Customer, bool, error) {
	params := &stripe.CustomerListParams{
		ListParams: stripe.ListParams{
			Context: ctx,
			Limit:   stripe.Int64(int64(limit)),
			StartingAfter: customerID // the last ID from the previous page or `nil` for first page
		},
	}

	iter := customer.Client{...}.List(params)
	if err := iter.Err(); err != nil {
		return nil, false, iter.Err()
	}
	
	return iter.CustomerList().Data, iter.Meta().HasMore, nil
}

We're still working on a design to support your use case. I put up a WIP PR, but I would still prefer to avoid exposing a new method if possible, so we may go a different route.

[chanioxaris]

FWIW, I think what you need for your use case is to include the StartingAfter parameter as well, otherwise you'll only fetch the first page.

@mbroshi-stripe That's correct, i just omitted any extra parameters for the sake of the the example

We're still working on a design to support your use case. I put up a WIP PR, but I would still prefer to avoid exposing a new method if possible, so we may go a different route.

I see! Maybe there’s no need for an extra method and we could take advantage of the LastResponse property on each resource instead?
You could expose this additional information there, similar to what you did previously with RawJSON. I’ve noticed that it already includes not only resource related data but also more generic details like headers and the idempotency key

[mbroshi-stripe]

Our current thinking is to make a breaking change so that List returns a type that has Data() and Meta() methods, along with All() for auto-pagination. That meets both manual and auto-pagination use cases, and future-proofs the design if there are other fields we need to expose (with of course the unfortunate downside of introducing a breaking change). Jamming a page-level response (like HasMore) into each individual resource doesn't adhere to the principal of least surprise, so we decided against that approach. I put up #2179 with our current design.