#_timothee
1 messages · Page 1 of 1 (latest)
not sure I follow, it was the same with the Plan API
You could do ['subscriptions']['data'][0]['plan']
subscription.item[n].plan and subscription.items.data[n].price are objects that contain Plan or Price objects, and they both have a product field which is the prod_xxx ID. You always had to retrieve that object if you needed values from it
and you can do subscription.items.data[n].price
True, but before it would make sense to put informations like features etc. on the plan object.
It's a bit weird to add features and some other information on a price object.
thanks for the feedback
But maybe I should just do as before and put everything on the price object.
it's just how it's designed, the Product is the thing being sold, the Price is an instance of a price and configuration for selling it. Could definitely be easier, but in general we are moving towards including less in the API response by default and encouraging more use of expand or extra requests or caching in your DB etc
Our design is to simple cache the customer object, expanded with what's needed.
I don't know if it's the best approach, but the pros I see are : It requires only 2 database columns (customer id, customer data), It's simple.
Do you think we might need to organize differently ?
not sure what you mean, customer data is a bit vauge
It's the whole customer dict stored as a JSONB.
like you can have one column and just put a massive JSON string in it and parse it when retrieving, but then you're not really using a database
like you couldn't do things like search by properties of the customer data
You can query / search / sort JSONB.
anyway ,this is not really something I want to get into, it's too busy and we answer specific Stripe API questions here
yeah again, I can't get into this, we support 7 different languages and I can't know the details of every system out there
Sure I understand, no worries. 🙂