#Coach Leyton
1 messages ยท Page 1 of 1 (latest)
We have some rate limit info here: https://stripe.com/docs/rate-limits
"For most APIs, Stripe allows up to 100 read operations per second and 100 write operations per second in live mode, and 25 operations per second for each in test mode."
I'm in test mode, and I'm certainly not updating the subscription 25 times per second
Live mode and test mode rate limits are independent of each other
Could you share the subscription ID you're working with?
Sure, sub_1NGkWzHxbsbtU2J3ZyddcTcx
Also, as an aside, you may find test clocks helpful depending on what you're testing: https://stripe.com/docs/billing/testing/test-clocks
It's like once every few minutes, so not sure how I could be triggering the rate limiting
ah you are using test clocks already
I use clocks, they're a great feature ๐
I thought perhaps that I was accidently spamming the API on some other endpoint, and so the requests to update the subscription were failing, but as you can see here, this isn't the case:
I feel like the response body for rate limits should include the cooldown duration btw
still digging in to the error but what are you trying to test exactly? I only see some minor changes in each update request (e.g. changing the default_payment_method but nothing else
So the main thing getting updated is the priceId of the subscriptionItem. So basically, how much am I charging people. And then some meta-data for me to handle from the webhook to perform some business logic
For exmaple, the user might prefer to be on the "Lite" subscription plan, rather than the "Standard" subscription plan, and so I'd need to switch the price Id used
Got it. The error appears to be due to the number of new invoices that are being generated in a short amount of time
Taking a closer look
Okay yes, there are some limits to the number of new invoices that can be created for a single subscription in a short amount of time. It won't be typical in production to have customers change their subscription this often within the few minutes you were testing.
I see. I think it's reasonable to suggest that in test mode at least, that rate limit be lifted
or do you think there are some potentially negative implications of that?
well, not LIFTED, just raised
I mean, there could be. I'll flag it to our team for consideration but the suggestion may be to think about the behavior you want to allow in production. For example, would you want to place a limit yourself on the number of times a customer can change their subscription during a given billing period?
Still, heard on the rate limits
yeah, perhaps I should add some logic on my end to prevent that. Probably not going to though, I'll be real ahhaha. If a customer is switching their subscription so much, they're just taking the piss. Probably won't occur for 99.9% of users anyway, so it doesn't make much business sense to spend time implementing such logic.
But anyway, thank you for the help, I appreciate it.
To circumvent this issue, you think I could just delete the subscription and make a new one?
And is making invoices definitely only strictly rate limited relative to a particular subscription? For example, if I have 50 subscriptions made within a short amount of time (one minute or so), will I encounter any invoice related rate limiting? It's unlikely, but still, something to consider
Sorry for the silence! Was still puzzled by something I was seeing on my end
It looks like it all comes back to that test clock, actually
Taking a step back, the test clock is currently frozen at a specific time. While each of your requests to update subscriptions came in at different "real" times, in the world of the test clock, each of the generated invoices were being created at the same time
And is making invoices definitely only strictly rate limited relative to a particular subscription?
In this case, you were running into a limit for the number of new invoices created for the same subscription in the same minute
Since the test clock is still frozen at the same time, any continued calls to update this subscription without first advancing the clock will continue to fail
Does that make sense?
OHHHHHHH
that makes perfect sense
that's for that clarification
I'll keep the clock in mind going forward!
thank you for your help ๐
Of course, happy to help!