#inexorable_api

1 messages · Page 1 of 1 (latest)

indigo cargoBOT
#

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

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

marble juniper
#

Hi, taking a look

#

Can you share the exact event id where you expect the property?

#

I want to ensure that we're both looking at the same thing

clear loom
#

Hi, it was more of a general question to fix my app - but here's an example... evt_1RZ8z6GfkSQ4YJCtdZ6iAjYM

#

I can see other elements relating to subscriptions - but I'm looking for the "Stripe" way of doing things that gives me the best chance of stability for a while.

#

Specifically, I'm collating all Subscription and Invoice events together and requested the most up to date associated subscription from the API to provision services.

For this, I need a reliable way to resolve the subscription_id.

switch ($eventObjectType) {
case 'subscription':
$targetSubscriptionId = $eventObject->id;
break;
case 'invoice':
$targetSubscriptionId = $eventObject->subscription;
break;
}

This was my working code ... but it's stopped working. I'm looking for the most robust alternative.

marble juniper
#

You're using 2025-04-30.basil API version, which has some breaking changes: https://docs.stripe.com/changelog#2025-04-30.basil . You always refer to the ChangeLog document to confirm what changed and handle them accrodingly. As for that event, https://dashboard.stripe.com/test/events/evt_1RZ8z6GfkSQ4YJCtdZ6iAjYM you can we return subscription: sub_ under "lines": so you'd want that to tie that invoice to the subscription.

Moving forward as long as you do not change the API version, it will be reliably. If you do change the API version, you will need to review the changelog thoroughly.

clear loom
#

I'm deep into dev of a new version and I have a feeling I switched API in a bleary eyed 4-in-the-morning moment of tired mistakes - and forgot about i had. Explains the disappearing property at least.

As for the "new" way of reliably getting the subscription_id it seems you're forcing navigation to the "parent" object - that may or may not of the right type. Seems very convoluted and a bit hacky - although I get why I think.

I'll spend some time with the change doc and try and see how/why it's better. Feels very fragile at the moment.

#

I appreciate your time nudging me in the right direction. Totally forgot I had switched API versions.

marble juniper
clear loom
#

Yes I think I understand - much like the period start and end that also moved (i noticed that one but still didn't make the connection).

It feels a little fragile because the docs say the parent could be different object types. But I haven't coded it yet so I might feel differently once I've got an implementation. Just makes me nervous if I can't rely on a known object in a known place of a known type.

marble juniper
#

Happy to help

#

yeah, I totally get it. Hopefully, once you work with it a more, it will click.

clear loom
#

Thanks again - really do appreciate your time.
Off to implement ..... 👍