#tea-hanks_api

1 messages · Page 1 of 1 (latest)

thorn wharfBOT
#

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

📝 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.

opal leaf
#

👋 happy to help

#

getting caught up with our discussion of last week,

#

I'm not sure what you mean by

I guess I can skip everything we discussed in the thread linked above? And if yes, then what is the usecase for passing schedule and details for it?

#

so you can't use schedule_details when you pass the subscription ID

#

you need to pass the schedule ID

thorn wharfBOT
vast grove
#

So last week I was trying to create a preview invoice using schedule details

A subscription had a discount already. I scheduled a phase for it which continued using that coupon. Then I deleted the coupon and tried to create a preview invoice by specifying that deleted coupon in the phase details. This was throwing error while the actual transition silently handled this by discarding the deleted coupon etc. We discussed this all

Afterwards we discussed that when creating a preview we could check if a discount for a coupon already exist, and specify that in the phase details. If not then check if the coupon exists etc

But then I thought why do I even need to specify schedule details. I could just specify a subscription id for my existing subscription and preview invoice API might consider that attached schedule as well when creating a preview. Turns out it does

Here is the request ID req_bM2n5JL37bStP3. This request is to create a preview invoice for a subscription which has a schedule attached to it. In the schedule there is a coupon that is deleted

#

My point being that I realized that the way we were calling the preview invoice API in our backend was unnecessary. We do not need to specify all those phase details. We can just specify for what subscripton we wanna preview an invoice

Alternatively I can just specify schedule id too . Here is the request ID req_YU6xAXCJUPDNGf. The result of it is the same as for the request above

opal leaf
#

if you just want to preview the next invoice as-is, passing the subscription is all you need. the API picks up the attached schedule automatically, and you dodge the deleted coupon issue entirely. schedule_details is really for "what-if" scenarios — like previewing what happens if you add a new phase, change a price, swap a coupon, etc. same idea with subscription_details for subs without schedules.

#

so it all depends on what are you trying to achieve

#

in the "what-if" scenario, you should use the same fields you would use when updating the subscription/schedule to get the exact outcome of the invoice that will be generated

#

if you wish to use the update Subscription API then you would use subscription ID + subscription_details, otherwise for the update Schedule API you would use the schedule ID + schedule_details

#

I hope this is clearer now.

vast grove
#

Yeah I think it is pretty clear now. Our backend code is using Stripe since 2020. And back then the APIs were different. There was something called get upcoming invoice which is now deprecated in favor of preview invoice

Our usecase is to preview an upcoming invoice as-is. And for that I think passing subscription was good enough since the API picks the schedule on its own. And I am not making any changes to the schedule so there is no need to preview any what-if changes. I don't know why our backend code was passing schedule and schedule details, maybe for some legacy reason. But certainly I can ditch that now

I just wanted to confirm the results of my testing were intended behavior and not something that might change randomly

tawdry oyster
#

👋 Yes, this looks like intended behaviour to me