Hi all!
Been loving using the Stripe.js plugin from CoBubble.
@copilot Any idea how to update a customer’s subscription quantity? “Update a Subscription” only allows for Tax and Prorate options. Should I create a new Subscription and delete the previous one if I want to increment the quantity from 1 to 2? Seems like that would create a bunch of issues.
Thanks!
Chris
Sorry, solved it myself. Didn’t realize I needed to use Subscription Item for Quantity and Plan.
Hey @chris10,
That’s right - a Subscription is made up of Subscription Items which containt the Quantity attribute. Updating the ‘quantity’ of a Subscription itself wouldn’t exactly make sense, which Stripe realized too. 
The plugin here is a little confusing because you can “Create a subscription” (not item) with a quantity, but you can’t “Update a subscription” (not item) with a quantity.
Is that a bug?
Not quite, since that step is where the first Subscription Item is created as well. 
Ah, ok. Glad you told me that. I was creating a new Subscription Item after I created the Subscription because I wasn’t sure it was covered. Thanks!
No problem.
If you ever find bugs or would like to sponsor a feature, do let us know at plugins@cobubble.com. 
Sorry, one more quick question here…
How am I supposed to find a Subscription Item ID? There’s no way to do that through the plugin Bubble UI. There is no “Subscription Item” or “Subscription’s Item” when searching through the API options.
And “Subscription’s Object” just lands you on the default Bubble options, with no further Stripe selector.
It also looks like there is no Subscription Item ID available in the API (which explains why I can’t find it). But the UI is asking for one when updating a Subscription Item’s Quantity.
Thank you!
Bubble’s Stripe plugin and the Stripe.js plugin aren’t exactly meant to be used together, with the latter exposing the information needed; if not, just let us know at plugins@cobubble.com.
For the future: we don’t offer implementation help outside of Sessions.
@copilot Ah, I’m not using them together at all. This must be a bug with Stripe.js.
Noted on the help. Apologies!
did you solve this? i am facing same issue…how do we get subscription item id?
I would like to bump this thread and piggyback on @asker and @chris10’s questions to help provide resolution for the community on the mystery of the Subscription Item ID using Stripe.JS. Not to be confused with the Subscription ID, which are two different ID’s I’ve come to find out.
It appears there is no way to retrieve the Subscription Item ID via workflows, and I have not seen whether that has been confirmed by @copilot. I did email them separately and via their website customer service chat to see if I could get to the bottom of it, but I think it’s important to share here too incase something is amiss.
Here is my situation.
Upon a user signing up I created a workflow where a metered subscription is created for my user via Stripe.JS. This works well and good.
The problem is when I come to the point where I finally have to add usage units to the metered plan, the Stripe.JS workflow action to add those units requires a “Subscription Item ID”… But no where could I find how to successfully retrieve that information.
Typically the plugin is good about being able to refer to a previous results actions to obtain a bit of information, like when creating a new stripe customer, then being able to ask the plugin to retrieve results of previous step’s Stripe Customer ID, to say, to save in your bubble DB. However, that doesn’t appear to exist for the Subscription Item ID.
This is problematic for me because as you can see in the screenshot below to add usage to a plan requires the Subscription Item ID, which I errantly put the Subscription ID in before. I have no idea what I may be doing wrong, or if something was missed by the @copilot team.
What confuses me is that when a new subscriber is to added to Stripe via the sign up workflow, a Subscription Item ID (top line, prefix “si_”) is generated as evidence in the code in Stripe’s dashboard (screenshot below). However, that information does not appear able to be called upon to be retrieved into workflow actions.
When I manually take the Subscription Item ID from the Stripe dashboard code, and enter it into the (path) Subscription Item ID field in the “Stripe.JS Add Usage to a Metered Plan” workflow, it actually does work. But problem is how do we pull that data via workflows?
@copilot, can you please confirm whether we are not retrieving things properly, or if this aspect was missed in the plugin?
@marktuff, it looks like copliot’s Subscription API calls are not properly formatted, so you are unable to get the Subscription’s related Subscription Items. As a workaround, you could create your own API and then create an API call to “Retrieve a Subscription”.
Here you can see the API call “Stripe - Get Subscription”, that I setup above, being used in @copilot’s Stripe.JS - Platform - Update a Subscription Item action.
Hey @marktuff,
Thanks for sharing the information above. A couple things to make note of:
Prior to Bubble introducing manual initializations, plugin developers had to actually execute calls that would return any relevant fields that Bubblers (like you) may need access to for their application(s). For example, creating an actual test Charge in Stripe just to return a response that contains all of the Charge object’s fields so they can be made available in the plugin. As a result, many of the requests you see in plugins may simply be incomplete due to the initialization not being complete.
Third-party services tend to update their API architecture to support new features which may return payloads that are different than the payload returned by the version of the plugin developer’s API at the time of initialization. In turn, some requests in the plugin may support an API version that is no longer the latest offered by the API which makes things even more confusing.
Some features are implemented on a sponsorship-basis, where a user (or many) opted to prioritize development of features that may not have been implemented until way into the future if at all. Though developers may aim to implement features in-full, that is not always the case as the concerns of sponsor take priority.
We’ve long-seen the limitations and hurdles with the current plugin development model. Now more than ever, it’s an opportune time for us to introduce a more maintainable and scaleable model for API-related actions. We’re really looking forward to sharing the next iteration of our plugin development approach which will address the issues listed above and more, starting with the next major milestone of the Stripe.js plugin.
Thanks @copilot! Hopefully it’s non-breaking and doesn’t require us to redo all of our existing plugin actions.
Thank you for your response @copilot, very much appreciated. I can certainly understand (and respect) how plugin development can be akin to a moving target, and that sounds great on the new approach you are devising.
Do you have an anticipated ETA regarding the next update of the Stripe.JS plugin? Like @Kfawcett, I hope that all of our workflow actions can somehow be intact, but let us know how that shakes out.
@Kfawcett, thank you for your response as well. I am going to look into your suggested workaround. But correct me if I’m wrong, are you still requesting to GET the “Subscription ID” and not the “Subscription Item ID”, or you first need to get the Sub ID to get to the Sub Item Id? I hope that makes sense. Also, where are you getting the value that you put into the URL parameters Value field beginning with “sub_”? Your screen looks a little different than mine, are you using bubble’s API connector in the Plugins section?
Your mileage may very depending on how you’re using Stripe. My app has a few different plans. A user signs up and selects only one plan. When they select a plan, I perform two actions. First, I create a Subscription in Stripe. Second, I add the Subscription ID, number of seats purchased, etc. to the User’s Account in Bubble using the Result of the “Create a subscription” step.
Stripe actually creates two items when you perform the initial “Create a subscription” – it creates a Subscription for the user and it creates a Subscription Item.
Yes, I am using a GET with the “Retrieve a Subscription” API, not the “Retrieve a Subscription Item” API since I do not know what the Subscription Item ID is due to the limitation in copilot’s plugin. Since I stored the Subscription ID in Bubble when the User initially subscribed I can use it to get the one related Subscription Item.
In Stripe’s “Retrieve a Subscription” API, you’ll see multiple "id"s. The first starts with “sub” (i.e. Subscription) and further down inside “items > data” you’ll see one, or more, starting with “si” (i.e. Subscription Item) depending on how many subscription items you have for a subscription.
Out of habit, I do not use the API connector plugin to build my APIs, I use the Plugin Editor instead.
NOTE: I did notice a slight difference in the API structure when I set it up compared to how Stripe says it should look in their documentation. In the screenshot below you’ll see “Get Subscription (list)” for the Subscription Items. It evens says “Get Subscription item data” on the right, but that will not show in Bubble when you’re using the API – as shown in the initial post I made when it shows “Stripe - Get Subscription’s Get Subscription”. The second “Get Subscription” is actually getting the nested Subscription Item.
@Kfawcett awesome reply, thank you so much, I think I’m following. One piece I’m still unsure of (my apologies if this is fairly elementary) is how to find what to put in the “Value” field (circled in your original screenshot below).
If you enter a subscription ID into that field isn’t that only tied to one user account? Is the value you have entered there a dynamic gateway to all subscriptions in your app? If so where in Stripe do you get this value?
Any clarification would be much appreciated.
When you setup the API you need a subscription ID to help initialize the call – if you stored that in Bubble when you subscribed the user you can grab it from whatever data table you put it in for the User for the initial setup of the API, otherwise you’ll need to go to Stripe and find it – but you really need to capture it in Bubble when the User subscribes for future referencing.
We need this so Bubble knows the structure of the API. The “Public” by the parameter means that when you are using this in Bubble workflow this will become a dynamic value that you’ll pass in.
Below I am clicking on the yellow which opens up the “Stripe - Get Subscription” dialog that I set up. In there is the one parameter we setup in the API call “subscriptionID” which is being passed a dynamic value (Current User’s account’s stripeSubscriptionID) that I store in Bubble.
Hi @Kfawcett, thanks. So you are saying that when setting up the API I can use any of my users’ Subscriber ID’s to enter into that Value field, which teaches Bubble what kind of string structure it needs to look up to eventually find the elusive Subscription Item ID?
So it only informs Bubble of the structure and has no direct affect on that particular Subscriber ID.
