Any way to force rate limit or quota exceeded errors for testing & QA?

Cornershop Creative

Our new RE NXT SKY API integration approaches QA. We believe we've got error handling code in place to properly process rate limit (429) and quota exceeded (403) status codes, relying on an async queue system to reschedule as directed by the retry-after HTTP response header.

We'd rather not throw thousands of junk requests at the SKY API during QA to push past the per second & per day caps.

Is there any way to force rate limit & quota exceeded HTTP responses on a per-request basis? Or temporarily on a per application-environment basis for our partner developer subscription? I couldn't find one in the docs of community discussions.

Ben Lambert

Hi,

Thanks for the great question!

At the moment there's no way to force the throttling mechanisms (rate-limit and quota). This is a new request that we've not heard before, but it's an interesting idea and I can envision some easy ways we could introduce this concept as a new feature to help test the robustness of your code.

Do you have any preference on how you'd like this to work? For example, we could support a new request header (like x-simulate-ratelimit: true) to allow you to simulate getting a rate-limit (or quota) response? Would that be sufficient?

Steven Cinquegrana

Seconded. Exceeding the rate limit for testing is easy enough but it would be good to be able to test quota-exceeded as well.

As I've posted elsewhere, I think there should also be connection test endpoints for each API. Currently, we wrap the lightest-weight call we can find for each API into a TestConnection call for our SKYLib•NET library and SDK but a dedicated call would make life easier, and would reduce load on the BB servers (since the call would not have to interact with back-end data).

Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Warren Sherliker

A simple /ping which maybe returns quota info? We likewise have to poll a normal data endpoint to check the connection. A user info or ping endpoint would be much better.

David Zeidman

@Ben Lambert I would second the idea to have a header to simulate a rate limit. We have also worried about the robustness of our handling code. We think it works but having a mechanism to make sure without sending through too many calls would be preferable.