roastedfalafel_webhooks

[silver widget]

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

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

[tender owl]

Hi 👋

For confirmation emails, I would always recommend relying on the invoice.paid event.

Can you tell me what properties of the previous_attributes you find useful in your flow?

[vocal spoke]

if ("items" in previousAttributes && previousAttributes.items) {
  const planIs = memSub.plan;
  const planWas = new MembershipPlan(
    previousAttributes.items.data[0].price as RecurringPrice,
  );

  switch (Membership.levelChangeType(planIs.level, planWas.level)) {
    case "upgrade":
      return await enqueueAppEvent({
        type: "membership_subscription_upgraded",
        subscription: memSub,
        prevPlan: planWas,
      });
    case "downgrade":
      return await enqueueAppEvent({
        type: "membership_subscription_downgraded",
        subscription: memSub,
        prevPlan: planWas,
      });
    case "renewal":
      return await enqueueAppEvent({
        type: "membership_subscription_renewed",
        subscription: memSub,
      });
  }

  ...```

eg comparing the previous price to the current price

doing this outside of the customer.subscription.updated event means keeping track of this state and looking it up on invoice.paid

nothing impossible about it but it means i have to do work stripe is already doing for me

[tender owl]

Got it. So in this case you are using the previous price -> current price to inform the message sent to the user.

[vocal spoke]

also, not sure how I should feel about not trying to be talked down from my offensive exception throwing idea. though now that I’m cooling off a bit from the pain of stumbling into this issue I’m beginning to see reason on my own 😄

[tender owl]

Sorry for the delay, it's been a busy morning. Unfortunately the first thing that jumps to my mind would be to store the change locally and then retrieve it when the invoice is paid (I'm one of those devs who loves to have my own DB).

[vocal spoke]

of course, thanks for your input. have a nice day

[tender owl]

I'm happy to shed what little 💡 I can 🙂

[vocal spoke]

oh one thought, i guess i can't count on getting the invoice.paid event after the customer.subscription.updated?

so i'd need to track this state across billing periods?

[tender owl]

Oh, correct! We cannot guarantee the order of webhook events if the changes occur around the exact same time

Is the cutomer updating their subscription using an interface you control or the Customer Portal?

[vocal spoke]

yah. i think i have a solution: find the last paid invoice for the subscription before the latest_invoice of a invoice.paid event and use the line item information the same way i'm using previous_attributes.items currently

[earnest crag]

Hi there. Snufkin had to step away. Do you have any follow up questions?