#nickherrig - subscriptions
sturdy plank
Hello. One moment while I catch up here
You can change the limit in the request to as much as 100 if you like: https://stripe.com/docs/api/prices/list#list_prices-limit
We always recommend storing as much as possible on your end, though, to reduce the number of requests to Stripe and avoid potential rate limiting in the future as your service grows
You can also use auto pagination: https://stripe.com/docs/api/pagination/auto
hazy hatch
I think you misunderstood specifically what I'm talking about. Here is a code snippet
lookupKeys := []string{"testlookupkey", "foo", "bar", "baz",
"blah", "bule", "blip",
"blah", "bule", "blip",
}
params := &stripe.PriceListParams{
Active: stripe.Bool(true),
LookupKeys: stripe.StringSlice(lookupKeys),
Type: stripe.String("recurring"),
}
params.AddExpand("data.product")
i := app.sc.Prices.List(params)
There appears to be an limit on the length of lookupKeys I can pass to the LookupKeys params.
There isn't a way to bump up that limit correct?
hazy hatch
RIP
What is the value of utilizing "lookup_keys" rather than just storing price_ids in a db then?
sturdy plank
It can be used as an extra field to group prices by and filter by them
When listing multiple prices
Just a way to categorize them
hazy hatch
but a lookup_key is "unique" though correct?
As in I cannot apply one lookup_key to 10 prices
so what's the different between stripe.Prices.list(lookup_key") and stripe.Prices.Get("price_id")
I actually would really like to apply one lookup key to 10 prices, is that possible?
If lookup_keys are unique to prices, and price_ids are also unique, then what value do lookup_keys provide?
stripe prices update price_fooobarbaz --lookup-key "testlookupkey"
{
"error": {
"message": "A price (`price_barbarbaz`) already uses that lookup key.",
"param": "lookup_key",
"type": "invalid_request_error"
}
}
Yeah they're unique. This is a good explanation actually: https://stackoverflow.com/a/64723593/17627350
hazy hatch
Ahh, this makes sense. So from your perspective @sturdy plank lookup_keys definitely have a place in the architecture. The mechanism of fetching price_ids with lookup keys needs to have logic that if the cart has 11 prices, it will need to make two stripe.Prices.List() calls to utilize this data in a checkout session, otherwise I'd need to just keep my own products database table in sync with the price_ids in stripe? In a nutshell.. custom build-a-box models like ButcherBox require a little more application state than utilizing stripe as the source of truth for products/pricing
The only other option I see, which would also make the User experience fairly slow, would be to grab all prices, and filter based on metadata, which doesn't sound like a good time
sturdy plank
Correct, to reduce the number of Stripe API calls, it's absolutely a good idea to have your own datastore
hazy hatch
is the idea that /webhook events are utilized to keep your integration in sync? For example, if I create a price in stripe dashboard, then a price.created even is fired, in which I could catch that an update a table?