I’m building an app where users get monthly “credits” and throughout the month they will use those credits. Each user has a “total credits” field and a “used credits” field, and what I’m trying to do is reset their “used credits” field at the end of each billing period so it’s back to zero.
In Stripe, each customer that’s subscribed to a plan has a “current_period_end” value that’s sent to Bubble through a webhook each time their subscription is updated. Question is: How can I schedule a backend workflow to run on that exact date/time for each user, so I can then make a change to their “used credits” field and set its value to 0?
I have a webhook setup that listens for the customer.subscription.updated event and sends the data to Bubble and then I run an API workflow to update the user’s data fields like Stripe Plan, Frequency, etc. This event occurs whenever a subscription changes (e.g., switching from one plan to another, or changing the status from trial to active). But what if the user updates their subscription before that billing period end date? Or what if they’re on the annual plan so their end date is a year from now? (meanwhile I want to update their used_credits monthly)
I thought about setting up an API workflow to receive the customer.subscription.updated event and to only run and set the used_credits value to 0 When that user’s current_period_end equals current date/time.
But that feels risky as the dates might not always match 100%, especially if there’s a slight delay between the data being sent by Stripe and received by Bubble. And it also doesn’t address the problem with the annual users not having a monthly end date.
The solution works except it’s not really recurring as it only runs once (a month after current date/time). If I want it to schedule this workflow to run every month for a year, do I have to create 12 steps, one for each month? Is there a more efficient way?
For what it’s worth, @duracel, the solution in the other thread is recurring due to the second to last screenshot in my reply. The step in that screenshot schedules the backend workflow to run again (recur) a month later, and I always use that method rather than using recurring events.
I don’t know your app, so I don’t know if that will actually work (and that has nothing to do with the recurring part), but you definitely do not want to schedule that workflow to recur every second. How would you even test that? If you reset the credits every second, then once they are reset the first time, you are simply resetting them again every second. Is that workflow running now? If so, you need to cancel it asap.
Try setting it to schedule itself in like 5 minutes, and then reduce the number of credits between the first time the workflow runs and 5 minutes later when it runs again.
I deleted it but it’s ok, even though it’s scheduled for every second it’s only triggered when I update a subscription in Stripe (and the app is not live yet, I’m the only one making changes to it). But regardless, even when I do update a subscription (from the stripe dashboard), this workflow only runs once (it gets scheduled for 1 second after the time I updated the subscription).
When I update the subscription in Stripe I check for two things:
The server logs in bubble. They show that the workflow only ran once. Here’s an example:
I check the user database. There, once the user’s “usage_this_month” has been set to 0, I manually change it to some random number like 777, save it then refresh the database every few seconds to see if that number was reset to 0, which it wasn’t.
Lol you’re right. It’s my first time looking at server logs so I was just looking for what I wanted to see (the usage_this_month value changing), wasn’t sure how to read them initially. The problem was with the first screenshot I posted:
thanks to 
it works now that I changed it. Thanks both