Folks:
I’d like to test the .Net SDK handling of 429s, so I provided this as the base URL when creating the client:
https://httpstat.us/429/
This does not eventually result in the request throwing a SquareApiException with StatusCode == 429 as would reasonably be expected. It instead throws this:
System.Text.Json.JsonException: 'T' is invalid after a single JSON value. Expected end of data. Path: $ | LineNumber: 0 | BytePositionInLine: 4. ---> System.Text.Json.JsonReaderException: 'T' is invalid after a single JSON value. Expected end of data. LineNumber: 0 | BytePositionInLine: 4.
...
at System.Text.Json.JsonSerializer.Deserialize[TValue](String json, JsonSerializerOptions options)
at Square.SquareApiException.BuildMessage(String message, Int32 statusCode, Object body, JsonElement& jsonElement)
at Square.SquareApiException..ctor(String message, Int32 statusCode, Object body)
at Square.Merchants.MerchantsClient.<ListInternalAsync>d__8.MoveNext()
It looks like the SquareApiException constructor isn’t robust to “malformed” response payloads…
The httpstat.us web page says:
To get a JSON response back, you need to ensure that the Accept header contains ‘application/json’. Then we’ll JSON encode the response and send the Content-Type header accordingly.
From the error it looks like the SDK API request isn’t including an Accept header with application/json. I’ve been unable to confirm this.
How would we test the 429 handling? Is there a dedicated Square API test endpoint somewhere that will always return predictable errors?
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
Additional Documentation
Handling Errors
Square .NET SDK Quickstart
Using the REST API
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
The Square .NET SDK does not currently provide a built-in way to simulate a 429 RATE_LIMITED error for testing purposes. The SDK is designed to interact with Square’s API endpoints and expects responses in a specific format. When you use a different URL, like https://httpstat.us/429/, the response format is not what the SDK expects, hence the error you’re seeing.
To test the 429 RATE_LIMITED error handling, you would need to create a scenario where your application sends a high number of requests to Square APIs in a short period of time, causing Square to temporarily stop processing your requests and return RATE_LIMITED errors. However, this approach is not recommended as it could disrupt your application’s normal operation.
As for the Accept header, the Square .NET SDK automatically sets this to ‘application/json’ for all API requests, so you don’t need to set it manually.
This answer was reviewed by @Bryan-Square.
To test the 429 RATE_LIMITED error handling, you would need to create a scenario where your application sends a high number of requests to Square APIs in a short period of time, …
That is absurd.
Can we please get a dedicated test endpoint for this?
Thank you.
Square uses dynamic rate limiting that adjusts based on several factors:
- Current API load
- Endpoint type
- Overall system health
Rather than having fixed limits, this adaptive approach allows us to:
- Scale with customer needs
- Prevent abuse
- Maintain system stability
- Provide better service during peak times
Why We Don't Publish Fixed Limits
We don't publish specific rate limits because:
- Limits are dynamically adjusted
- Different endpoints have different thresholds
- Publishing fixed numbers could encourage "limit racing"
That information would be more appropriate on the other question I just asked about implementing proactive rate limiting, at Proactive rate limiting vs. reacting to 429s? - Questions - Square Developer Forums
It doesn’t satisfy the request for a 429 test endpoint in your APIs, as the logic you use server-side to determine when to respond with a 429 doesn’t affect whether or not the client (either your SDK code or our application that’s using your SDK) handles the 429 properly.
I’m sure your SDK does handle it properly, but I want to be able to prove that, and to test our handling of the error returned by the SDK.