#Jeffrey-subscriptions

1 messages · Page 1 of 1 (latest)

jagged portal
#

Hi there!

snow adder
#

Hey, thank you for the fast reply.
yes in the response is the sub_sched_1LAVzdD2p4ov5QvNIg5FcoJ9 but when it gets converted into the final sub it looks like this: sub_1LAW4AD2p4ov5QvNcLLZatfH

jagged portal
#

Oh, I see what you mean. Give me a few minutes to look into this.

#

So you will get a few webhook events when the subscription is created: subscription_schedule.updated, customer.subscription.created, and invoice.created.

#

And when that happens, the subscription schedule object will have a subscription property with the subscription ID.

snow adder
#

Thank you for the hint, I check subscription_schedule.updated webhook event but cannot see the subscription id in the event

formal kernel
#

Can you share the evt_xxx ID?

snow adder
#

This ID?
evt_1LAWabD2p4ov5QvNpscCzKcb

formal kernel
#

Thanks, taking a look

#

Hmm, that's not a subscription_schedule.updated event

#

At this point the subscription is released from the schedule, so its expected that subscription field be null

snow adder
#

sorry for that this is the updated event
evt_1LAWaaD2p4ov5QvN8v9quYZr

formal kernel
#

The same issue really, the subscription is released at that point so its no longer controller by the schedule

#

What is it you're trying to do exactly?

snow adder
#

We need the subscription id so our customer can press our cancel button, but the sub_sched_ is not longer working because it gets exchanged with the new sub ID

formal kernel
#

Why can't you just rely on customer.subscription.created events?

#

You're creating the schedule with a single phase, so the subscription is created and immediately released from the schedule

#

That subscription field is always going to be null in that case