johanvaneck_api

[tall flume]

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

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

[meager lark]

Hello, thanks for the info, taking a look

[pine leaf]

Thanks!

[meager lark]

Can you double check if you sent the right event ID? When I look at that event I see cancel_at_period_end set to true

    cancel_at_period_end: true,
    canceled_at: 1753111165,
    cancellation_details: {
      comment: null,
      feedback: null,
      reason: "cancellation_requested"
    },```
Also as far as I can see a schedule was never connected to that specific subscription

[pine leaf]

Investigated now. It appeared to have worked for the following event:

evt_1RnPxMDmuqIMmGLr4z0wUZ2v

but not for this one:

evt_1RnQ13DmuqIMmGLr4tVeEjrB

[meager lark]

I am seeing cancel_at_period_end as true for both of those events. Is it showing false somwhere else like when you retrieve the object?

[pine leaf]

Yes. When listing the subscriptions, I get the following for the second event's subscription:

{
"id": "sub_1RnLcTDmuqIMmGLrSOvhLImg",
"object": "subscription",
...
"cancel_at": null,
"cancel_at_period_end": false,
"canceled_at": null,
"cancellation_details": {
"comment": null,
"feedback": null,
"reason": null
},
...
"schedule": {
"id": "sub_sched_1RnLcjDmuqIMmGLrFr5ANHTF",
"object": "subscription_schedule",
...
},
}

So the events would be

evt_1RnQ12DmuqIMmGLr8hZHy9TU (release sub sched)
evt_1RnQ13DmuqIMmGLr4tVeEjrB (update sub)

[meager lark]

And that is still the case if you retrieve it right now? I see that the request that set this to true came after that first event (and is actually what triggered the second event) so I would expect it to be false if you retrieved it after receiving the first event and true if you retrieved it after receiving the second event. But you are saying here that retrieving the subscription after receiving the second event that it still shows as false?

[pine leaf]

That is correct

I use the list endpoint, but it should be the same.

I just tried it again. This is the response from the update event:

{
"id": "sub_1RnLcTDmuqIMmGLrSOvhLImg",
...
"cancel_at": 1761060433,
"cancel_at_period_end": true,
"canceled_at": 1753130083,
"cancellation_details": {
"comment": null,
"feedback": null,
"reason": "cancellation_requested"
},
...
"schedule": null,
...
}

However, after this event, doing a list subscriptions, I get this:
[
...
{
"id": "sub_1RnLcTDmuqIMmGLrSOvhLImg",
"object": "subscription",
...
"cancel_at": null,
"cancel_at_period_end": false,
"canceled_at": null,
"cancellation_details": {
"comment": null,
"feedback": null,
"reason": null
},
...
"schedule": {
"id": "sub_sched_1RnLcjDmuqIMmGLrFr5ANHTF",
...
},
...
}
...
]

I need to go now, but will respond again in about 10 hours. Would appreciate your help in resolving this issue 🙏 I've been stuck on this almost the entire day.

[white drum]

👋 I know you're out but I'm currently trying to test this on my end, too. Will flag here if I find anything helpful!

[white drum]

Okay, I can't reproduce. I created a Subscription via Checkout, followed by a Schedule. I then updated the Schedule's phases and end_behavior, then released it from the Schedule.

I then updated the Subscription directly to set cancel_at_period_end: true. The event I received reflected this change. I then make a call to list all Subscriptions for my customer and the Subscription returned still reflected the correct value for cancel_at_period_end