#_subschedule-expandable-properties

1 messages · Page 1 of 1 (latest)

bright quartzBOT
#

👋 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/1407470497054199979

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

tepid gale
#

Hello 👋

Prices in SubscriptionSchedule phase items are not expanded by default. You can see we flag this in our API reference doc here

The phase.items.price property is a String type but we label it as an Expandable property. This means you can expand the Price object by specifying it in the expand parameter when making API requests.

Expandable properties are not expanded by default in webhook events.

errant steeple
#

is there a configuration that we can use on our side to have the webhook event to send us the price expanded?

tepid gale
#

Nope, that is not possible

errant steeple
#

ok, so we will need to poke the endpoint with the ids we get in order to fully get the objects

tepid gale
#

Correct

errant steeple
#

gotcha, thanks

tepid gale
#

Would these always be new Prices?

errant steeple
#

yeah, basically subscription price changes

tepid gale
#

I'm just wondering if you could ping you database to see if the Price already exists (using the ID in the event payload), and then only trigger the GET request for the Prices API if you don't return a result

#

That way you cut down on API requests and improve latency. But if those aren't concerns of yours then you can ignore that suggestion

errant steeple
#

To give you a little more context :
We have a plan structure on our database that translates into prices inside Stripe.
So we synchronize a customer when they change prices or schedule price changes, since in our database we store their current plan (stripe price metadata) and their future plan (when applicable).
That said, when we receive a subscription_schedule.updated means that we need to update the customer in our database to reflect their current plan (price from phase 0) and future plan (price from phase 1)

tepid gale
#

Okay but each Plan isn't unique to a single Subscription, is it?

#

It sounds to me like there's an opportunity for some data normalization that could cut down on the number of API calls

errant steeple
#

nope, a plan on our side can be even multiple prices at Stripe (cause each frequency on stripe is a different price, but for us it's all the same plan)

tepid gale
#

Okay. So you could have a table of Plans and a relationship entity mapping Plans to Prices and still look those up based just on the ID.

#

Then you only hit the API when you don't have an existing record

errant steeple
#

for example..
"Individiual plan" on our end has 2 prices: monthly and yearly.. so in stripe they're 2 diff prices attached to a same product..

#

And as of now we don't store any stripe ids

#

But we use our ids as metadata inside stripe

tepid gale
#

Got it. Okay so in that situation you'd need the full Price object so you can get the metadata parameter.

errant steeple
#

Yep, exactly, all this is to retrieve our metadata

tepid gale
#

Got it. So you will need to retrieve the Price based on ID.

errant steeple
#

Gotcha

tepid gale
#

Generally we recommend storing data like Price objects in your integration data storage to avoid hitting rate limits as you scale.

#

But that is more of a general recommendation and there may be reasons that isn't a suitable option for you

errant steeple
#

Since we're migrating from another provider to Stripe, we tried to keep it simple and as smooth as possible, that's why a couple decisions were taken, like to sync Stripe & our Database through hook calls, etc

#

But in a near future we will probably start moving forward to have some changes in order to make stripe to be our source of truth, instead of using our database for it

errant steeple
tepid gale
#

That makes sense. We're all under pressure to get solutions delivered and maybe don't always build things the most optimal way on the first attempt.

errant steeple
#

As of now the only thing we store are customer ids

#

Thanks anyway, I'll check how I can implement it on my end 😉

tepid gale
#

Have a good one!