#vajhatz-subscription-metadata

1 messages · Page 1 of 1 (latest)

gleaming sluiceBOT
small rain
#

@opaque marsh Unfortunately this isn't really something we support

#

vajhatz-subscription-metadata

opaque marsh
#

Hmm, I was wondering if attaching a line item that costs 0 but has metadata associated might be a solution 😅

small rain
#

don't really see how that could work with a Subscription. How do you "attach a line item" to a Subscription update?

opaque marsh
#

-d "add_invoice_items[0][price]"={{ONE_TIME_PRICE_ID}}

#

To create a subscription, combine a recurring price with a customer. To bundle one-time purchases with a recurring purchase, you can do so by using add_invoice_items

small rain
#

hum that could work I guess but that seems really weird to me

opaque marsh
#

I have to admit though, I haven't went through the whole end-to-end in documentation, like if I can attach temporary metadata to these items, but I'm thinking it probably doesn't work

#

I have a pretty common scenario though, where the client side starts a request that gets processed by the webhook, so in between these two events, my database items is out of sync.

#

I want to update the number of credits in a subscription, and also associate that one with a specific appId. So the thought was that I need this appId in the webhook in order to update the database entry for it, specifically.

#

Any tips would be appreciated, though I don't want to waste your time too much, I have a backup plan with a queue that might work, but wanted to get some clarification from source as product people are pushing for it. 😁

small rain
#

Yeah I can't really think of any way to do this that isn't a hack

#

I don't also get what an appId has to do with an update and why multiple would happen at the same second/minute so it's tough to say

opaque marsh
#

Hoping this might make a bit more sense, if you can think of anything, let me know, if not thanks for the help already! 💪😁

We have a button that unlocks a tier for an app (like PRO). So when someone with multiple apps wants to upgrade an app, they'd go to the page for an app, and start the flow to update the subscription quantity (+1) with the result being an increase in number of general credits (this happens from the webhook and in our DB), then the credit also needs to be associated with the app from where the flow started (this would also need to happen from the webhook and in our DB).

Go to App X page -> Choose to update -> Update subscription quantity (API) -> In webhook update database with metadata from subscription (increasing general credits for the customerID +1) -> [This step would be to update AppX tier, but there's no reference to AppX in the metadata].

small rain
#

How do you map "an app" to the Subscription though? Isn't there a different Subscription for each, or SubscriptionItem or something?

opaque marsh
#

Nah, a general subscription where quantity = number of apps you can of that particular tier

#

Account is 1 : 1 with subscription of type PRO, for example. And it has a quantity of 5. That means I can have 5 apps in that tier. The association is done with another database entry, which is the one where I'm trying to figure out how to link in the webhook now.

My 'hack' would be to create a queue where I have a list of requested credits for appIds, basically a queue of appIds, that the webhook would fulfill in FIFO style.

small rain
#

I see okay that's the bit I was missing

opaque marsh
# 
      case 'customer.subscription.created':
      case 'customer.subscription.updated':
        const {
          id,
          quantity,
          metadata: subMeta,
        } = event.data.object as {
          id: string
          quantity: number
          metadata: {
            accountURN: AccountURN
          }
        }

        await accountClient.updateEntitlements.mutate({
          accountURN: subMeta.accountURN,
          subscriptionID: id,
          quantity,
          type: ServicePlanType.PRO,
        })

        // Would add an extra step here for the association with the requester appId
small rain
#

And so could you set something like latest_app_id as metadata on the Subscription and rely on that?

#

So that every time you get a customer.subscription.updated Event you check the latest_app_idand whether it changed or not

opaque marsh
#

Well, in a sense yes, that was my initial thought, but latest_app_id gets persisted and I have a general buy credits button, that would be mistaken in the webhook from an app-started flow. So that would mean I need to update the subscription after a latest_app_id, which would in turn make the sub event run again 😅

small rain
#

you could do that and immediately unset it maybe?

opaque marsh
#

I think it creates another customer.subscription.updated event. If not this might work, but I had a strong feeling it would.

#

So this new event would be indistinguishable from a general credit purchase scenario.

small rain
#

I mean it would because that updated Event would only unset the metadata

#

and you could know to ignore it

opaque marsh
#

Hmm, interesting. Looking through the docs, I see no diff in the response, so allegedly I'd have to take care of figuring out that is's a metadata removal diff on our side. Either way, thanks a lot, I'll investigate this avenue! Really appreciate the help and patience! 😁 🙏

small rain
#

when you get a .updated Event, that's what you rely on to know "what was updated"

opaque marsh
#

Oh, that's great! Well this seems to solve the situation fully 😁 🚀

gleaming sluiceBOT
opaque marsh
#

🙏

#

Damn, apparently it seems the previous_attributes get set for the subscription's plan and price, not for the subscription itself.

small rain
#

no you're misunderstanding what you are looking at

#

Try this
1/ Create a Subscription with no metadat
2/ Update the metadata
3/ Update the metadata again to something else
4/ Look at each .updated Event and see that the metadata changed on each

#

(I have to run but my colleague can help if you have further questions they are already in the thread)