#josh_best-practices
runic hingeBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1337040673588903956
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
signal heath
I mean the Stripe feature called entitlements. When a customer subscribes to a product that has a feature associated with it their customer record is automatically tagged with an entitlement.
slow forge
ok I see what you mean now
in that case you can simply retrieve the entitlements per customer as described here https://docs.stripe.com/billing/entitlements?dashboard-or-api=api#list-active-entitlements
We recommend you persist these entitlements internally for faster resolution.
signal heath
Fair enough, it just seems like potentially a lot of requests. Fine on my end and yes I'll definitely cache the results. It won't be a page visited often anyway, I just wondered if there was a better way.
slow forge
we're not recommending caching but instead having these be reflected and persisted in your own database
signal heath
Oh right, but then I'll have to keep them in sync somehow for when subscriptions get updated. Doesn't that sort of defeat the purpose of the entire feature if I've also got to have a second source of truth for this?
slow forge
you can update them by listening to the webhook events we send when the entitlements change https://docs.stripe.com/billing/entitlements?dashboard-or-api=api#webhooks
and by that you would still have one source-of-truth which is Stripe
signal heath
OK I can certainly do that, thank you for your help. My feedback if desired would that this seems a little convoluted and maybe an area where the api could be improved.
slow forge
which part exactly?
runic hingeBOT
signal heath
Which part of the api do I think could be improved? I think some level of filtering on lists of all listable entities would be helpful. In a perfect world I feel like the data structure is a great use case for Graphql, but understand that's not the direction that's been taken. It just feels like getting the relational data is a bit verbose and keeping a separate record of relevant stripe data makes the features api much less useful. If I've got to keep track of changes via webhooks anyway I might as well just hook into the subscription api and update my database accordingly. Maybe I've misunderstood how stripe envisages people using the api and that keeping a second record of all relevant data on our databases is just best practice anyway, but if so that hasn't been clear to me until now.