Is it possible to exempt certain users in an instance, or even modify the whole instance at a config level in order to adjust the 429 response sensitivity when entering passwords? When testing our deployed applications, we have found that we’ll get the 429 response after only 5-10 valid attempts within a half hour.
Note that this is using the Stytch Vanilla JS SDK integrated into our Angular Application, using the prebuilt passwords UI.
Hey Joseph,
Thanks for posting!
It’s not possible to exempt specific Stytch Users from rate limits at the moment, but the password rate limit in particular can be reset with a successful password reset flow. Would this work for your use case?
we have found that we’ll get the 429 response after only 5-10 valid attempts within a half hour
To confirm, do you expect normal user login patterns to trip this as well, or is this just during manual testing flows? If the latter, I’ll also mention that rate limits are generally more forgiving in our Test environment than our Live environment to better support testing flows!
Hey Matt,
Thanks for the incredible response time, and for the insight.
Yes this is only for our manual test flow right now, so we can look into trying to use a test environment for this case. My only question off of that is can we have more than one test enviornment per project?
Of course - happy to help!
My only question off of that is can we have more than one test enviornment per project?
Each Stytch Project will have one set of Test API keys and one set of Live API keys. If you have multiple pre-production environments that you’d like to use with our Test environment, there are a couple of options:
- Utilize the same Test API keys across those pre-production environments.
- Each environment that shares API keys will also share user bases, configuration settings from the Dashboard, etc.
- Create separate Stytch Projects for each environment, and use the Test API keys from those different Projects.
- This option may fit if you’re looking for environment isolation, and want to keep the user bases and configuration separate across pre-production environments.