#deep_api

1 messages ¡ Page 1 of 1 (latest)

simple zincBOT
#

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

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

hollow swift
#

I need to know on each event - which customer account it was fired for, seems every event has a "customer" field so if that's true for every event then I'm good. Then I need to know when a subscription starts or renewed or cancelled.

#

But say with customer_updated event, how do I know if one update is them adding a subscription or making some other change like adding card info or address info.... It's hard to know which fields to check in each event to know exactly what type of specific event I'm parsing.

#

For instance, when I cancel a subscription I get - "customer.subscription.updated". But, the only fields I can find that seem to relate to cancelled sub's are:
"cancel_at": 1737428973,
"cancel_at_period_end": true,
"canceled_at": 1734752191,
But, it seems theses fields exist for other events and I would have check non-null value "to know" it's a "subscription cancel" event.

#

Is that how I do it? Read docs for each event, find fields that seem to be what I need and when a single event is sent for multiple uses (cancel, update, etc) then I check for specific fields and if they aren't null then I can assume the event is for "cancel"....?

#

I guess I would assuming there would be a specific "event / type.id" field that tells me exactly which event I'm looking at but events seems to be generated for multiple use cases but with the same event "type".

knotty dock
#

Hello, the best way to tell what a *.updated event is about is checking the event's previous_attributes fields. That will show you specifically which fields changed in the action that triggered this event

#

Can you tell me a bit more about what specifically you are trying to implement on your side when looking at these events? Happy to explain what each of these events do and when they are fired but I can tailor it a bit better knowing that

hollow swift
#

I see... let's just keep it simple for now. In the case of cancelled subscription, I see these previous_attributes:
"previous_attributes": {
"cancel_at": null,
"cancel_at_period_end": false,
"canceled_at": null,
"cancellation_details": {
"reason": null
}

#

so, to "know" what type of update event this is, I would have to create a list of fields that I would expect to see in this previous_attribs structure?

#

and if I don't find "cancel_at" then it means it would another type of event and keep parsing/searching for attributes I need for different "update events?

#

For my SAAS, I have these billing use cases:

  • Buy subscription (first time subscriber)
  • Renew subscription
  • Cancel subscription
    When they change their subscripton from Product A to Product B (say they upgrade from PRO to TEAM subscription), I need to know
  • Cancel old subscription
  • Buy subscription (the upgraded product, might an upgrade from monthly to annual subscription or it might be moving from basic to advanced product)
knotty dock
#

Gotcha, in that case yes, checking for the cancel_at field to be set is a good way of listening for this. cancel_at being null in previous_attributes indicates that at least part of this change was scheduling the subscription to cancel in the future. A customer.subscription.deleted event will fire when the cancel_at time comes and the subscription is fully cancelled.

hollow swift
#

I see. This cancellation event I logged was when I manually cancelled as a test user.

#

Not expiration of subscription.

knotty dock
#

Can you send me the subscription ID for this (sub_123)?

hollow swift
#

But, ok good, so this is helping. I need to inspect previous_attributes to know what type of, let's call it, "sub type" of event I have actually received.

knotty dock
#

And was this cancellation through the Customer Portal or was this from something that triggered a cancel API call from your server?

hollow swift
#

Bc for instance, customer.updated gets called a lot.

#

All of my testing is only through the Billing Portal (for cancel / upgrade) and the Hosted Checkout Session page for (Buy Subscription)

#

sub_1QYIANCs82YH7HIBXacoObDf

knotty dock
hollow swift
#

And thanks, yes, if you could point me to the fields / "main" event for say "Buy Subscription" and when a "Renew Subscription" occurs, that would help a ton

knotty dock
#

One thing to keep in mind here is that the customer portal has a setting for cancelling subscriptions immediately when a customer clicks cancel, or just scheduling the cancellation for the end of the billing period

image.png
hollow swift
#

Yep, I've played with those settings.

knotty dock
#

For the initial payment invoice.paid is often the easiest event to listen to. Invoices have a billing_reason property that will be set to subscription_start if it is the first payment on the subscription (there is a bit more detail here if you use free trials). Otherwise you can also listen to customer.subscription.updated and check for events that represent status becoming active

#

For subscriptions renewing the same two events work. invoice.paid and check for billing_reason='subscription_cycle' or customer.subscription.updated and check for current_period_start and current_period_end changing

hollow swift
#

man THANK YOU

#

good lord, i've been struggling for a couple weeks reading everything i can find to understand all the events that could get fired, which fields to use, etc etc etc

#

ok this is super helpful

#

what's odd is in my log capture (i saved all the events for a single subscription purchase flow - pick a product / enter card info / buy subscription), I don't have an "invoice.paid" event at all

#

but I do have the cust.sub.updated event

#

i also have cust.sub.created

#

For my "buy subscription" use case test, these are the events I captured:
"checkout.session.completed"
"customer.updated"
"customer.subscription.updated"
"checkout.session.completed"
"customer.updated" (again)
"payment_intent.succeeded"
"customer.subscription.created"
"payment_intent.created"

#

I was thinking I would look only for "checkout.session.completed" event to know when a customer buys a subscription. But, maybe I should use "customer.subscription.updated" and look for "status: active"?

knotty dock
#

And yes very good point checkout.session.completed is a great event for that first payment

hollow swift
#

ok i see, yes, you're right

#

i prob didn't subscribe my endpoint to "invoice.*"

#

got it

knotty dock
#

You can do whichever makes the most sense for your integration. These events are largely redundant and often the decision comes down to which object has the most relevant data do your integration.

hollow swift
#

ok i see

knotty dock
hollow swift
#

For subscriptions renewing the same two events work. invoice.paid and check for billing_reason='subscription_cycle' or customer.subscription.updated and check for current_period_start and current_period_end changing ---

#

(yes, i've read that, i'll continue reading it too bc i'm still learning)

#

ok, so it's reliable to use "cust.sub.updated / current_period_start and _end to capture "subscription has renewed or subscription has ended"

knotty dock
#

In this case it should always be for a renewal. If the subscription ends suddenly, the current_period_start would stay the same. I think the current_period_end might even stay the same but I forget. The other thing that would change those fields would be updating the subscription in a way that makes a new cycle start immediately, so either changing cycle length (eg monthly->yearly) or if you make an update and specify to reset the billing cycle anchor to now

hollow swift
#

ahhh, i see

#

ok i think this gives me enough to start wrapping up my webhook testing..... i'll circle back here to this thread with any questions if that's ok