#Coach Leyton

1 messages ยท Page 1 of 1 (latest)

clear sigilBOT
tall oar
cursive fable
#

"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

tall oar
#

Live mode and test mode rate limits are independent of each other

#

Could you share the subscription ID you're working with?

cursive fable
#

Sure, sub_1NGkWzHxbsbtU2J3ZyddcTcx

tall oar
cursive fable
#

It's like once every few minutes, so not sure how I could be triggering the rate limiting

tall oar
#

ah you are using test clocks already

cursive fable
#

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

tall oar
#

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

cursive fable
#

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

tall oar
#

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.

cursive fable
#

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

tall oar
#

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

cursive fable
#

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

tall oar
#

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?

cursive fable
#

OHHHHHHH

#

that makes perfect sense

#

that's for that clarification

#

I'll keep the clock in mind going forward!

#

thank you for your help ๐Ÿ™‚

tall oar
#

Of course, happy to help!