Is x-amzn-RateLimit-Limit response header working?

[Amrac]

Hello, I'm currently building my software with respect to Selling Partner API's usage plans, and I do not get the x-amzn-RateLimit-Limit in the headers.

Could you confirm that this feature is currently working and that I should get this x-amzn-RateLimit-Limit header?

`array(1) { [0]=> string(265) "HTTP/1.1 429 Date: Sat, 31 Oct 2020 09:44:43 GMT Content-Type: application/json Content-Length: 134 Connection: keep-alive x-amzn-RequestId: 08994608-0658-4072-b813-88a208b8e506 x-amzn-ErrorType: TooManyRequestsException x-amz-apigw-id: VRTB2HecDoEF2yA=

" }`

array(1) { [0]=> string(134) "{ "errors": [ { "message": "You exceeded your quota for the requested resource.", "code": "QuotaExceeded" } ] }" }

[parvathm]

Hi,

Sorry for the confusion, x-amzn-RateLimit-Limit header is yet to be deployed. We will update here once it is deployed”.

Thanks, Parvathm, Amazon MWS Support.

[johnkw]

Is the plan to have x-amzn-RateLimit-Limit returned with every call, or only with a 429 error? It sure would be useful to have information on the token bucket returned with every call, so you can just sleep between calls as directed, instead of waiting to hit a 429 error.

[parvathm]

Hi,

Sorry for the delay. x-amzn-RateLimit-Limit should now be returned in response headers in most of the calls. If you are still not able to receive please let us know.

Thanks, Parvathm, Selling Partner API Developer Support.

[johnkw]

We're not receiving that header, even with a 429 error. For example from a /products/pricing/v0/items/x/offers call:

429
Date: Sat, 20 Mar 2021 14:44:24 GMT
Content-Type: application/json
Content-Length: 134
Connection: keep-alive
x-amzn-RequestId: 0ca75a50-44cd-474e-bb0d-270d3c729cc4
x-amzn-ErrorType: TooManyRequestsException
x-amz-apigw-id: cfaLSHAloAMFSTg=
{
  "errors": [
    {
      "message": "You exceeded your quota for the requested resource.",
     "code": "QuotaExceeded"
    }
  ]
}

[mingxin-yang]

@parvathm

[johnkw]

I just ran a test and this header does exist now. However it seems to be not very useful. It only returns the sleep count, but nothing about the burst amount, or the amount of the bucket that you used.

For example GET /fba/inbound/v0/shipments just always returns x-amzn-RateLimit-Limit: 2.0. But the burst is an enormously generous 30. So there's no reason to sleep for that normally. At a bare minimum that header should return the burst, like 2.0;30.0 or something. But that would still be mostly useless.

To actually be useful it needs to return your current bucket number also. So 2.0;30.0,xxx for example, with xxx being the variable part.

[johnkw]

In addition to the above, which would help correct rate limits for some calls, I just realized there's another gaping hole in this API, in order to make it usable. The x-amzn-RateLimit-Limit header needs to return the OPERATIONs and PATHs that this limit applies to.

With a call like GET /products/pricing/v0/items/{Asin}/offers for example, the OPERATION is obvious enough: GET. But the PATH that this limitation applies to is apparently /products/pricing/v0/items/*/offers, which would require a generic client to perform a pattern-match on that PATH in order to know whether to sleep or not.

[github-actions[bot]]

This is a very old issue that is probably not getting as much attention as it deserves. We encourage you to check if this is still an issue after the latest release and if you find that this is still a problem, please feel free to open a new issue and make a reference to this one.

[johnkw]

This is still quite broken.

The documentation is now at https://developer-docs.amazon.com/sp-api/docs/usage-plans-and-rate-limits-in-the-sp-api but it still doesn't say how x-amzn-RateLimit-Limit is intended to be used.

Also as per my Sep 1 and Apr 16 comments above, the x-amzn-RateLimit-Limit field is almost entirely useless. To be useful it needs to return: refill, burst, current bucket, applicable path pattern.

[rugved1991]

Hi @johnkw,

The rate limit header should be used as a reference for limits on operations for specific sellers. This header plays a major role when working with Orders API as it has Dynamic Usage Plan. We have taken your request as a feature request on adding more details to the rate limit header. We currently do not have any ETA on if and when this feature would be made available for public use. Please look out for announcements on the SP API website for latest updates.

Best, Rugved Solutions Architect, SP API

[johnkw]

It would be preferable to leave this open until it's in a more usable state, or open a new enhancement bug linked specifically from this bug. Google finds this when looking for "x-amzn-RateLimit-Limit", and this is where people are likely to look, not the announcements.

[hypogealgaol]

Has anything changed in the implementation of this header since the previous post?

[johnkw]

No this is still broken and this issue should remain open @rugved1991

[tspicer]

@rugved1991 , do the sellers, the selling partner app developer, or both need to request that support for increases to the API limits? For high-volume sellers, we consistently get throttled. At the moment, it needs to be clarified who should be taking points on limit increases. Do we do it on our app account? Do sellers do it on their seller accounts referencing our app ID? Please advise.

[rugved1991]

Hi @tspicer,

The throttle limit is on the API calls. So the app developer needs to manage the call volume for their sellers by adding back-off mechanisms. If you are running into throttles for high volume sellers, you should first make sure you are using the recommended workflows for the use cases which enable batch or bulk methods. You can check out this Blog for more information: https://developer-docs.amazon.com/sp-api-blog/docs/strategies-to-optimize-rate-limits-for-your-application-workloads If you are still running into throttling issues, then please open a developer support case and request a rate limit increase for the specific API operation. Please provide details of your workflow and what limit you need to achieve your use case. If it is required for a specific set of seller accounts, you would need to share a list of seller IDs that need higher throttle limit. The support team will investigate and recommend accordingly.

Best, Rugved Solutions Architect, SP API

[tspicer]

hey @rugved1991 , thank you for the response. I hope all is well.

Yes, we have followed those steps. The issue is largely related to order items, though not fully. For example, if we have a seller with 2000 orders between 2 PM and 3 PM, there can be 3000 to 5000+ order items. If that volume is repeated from 3 PM to 4 PM, then 4 PM to 5 PM, and so on, you will quickly have a significant compounding backlog of requests due to limits.

Any latency in the API response will further compound the backlog of queued retry requests.

To date, we have employed an hourly request strategy with an offset +30 minutes. For example, at 3:30 PM, we will request updated orders and order items from 2 PM to 3 PM. Requesting a longer time period, say 2 hours, 6 hours, or 24 hours, would compound the failed requests due to limits. Calling more quickly, say every 15 minutes or 30 minutes, would often miss orders, which may be a function of how data is settled in Amazon systems. As a result, we settled on the hour grain as a reasonable compromise.

[johnkw]

That issue is not even slightly related to this bug report. This bug report is only about the x-amzn-RateLimit-Limit is totally unusable and broken right now. Those comments about increasing limits should be put in a new ticket.

[tspicer]

@johnkw , not slightly related to this report? Your response earlier in this thread was that the header is working but not useful. You then called it working but broken. If you want to nitpick, then you should have started a new ticket once the original bug of the header not being present was resolved by Amazon. It is present.

As you stated, the header does not work in the manner needed, especially at scale. At the moment, we are left to develop a series of strategies for request backoffs, re-queueing requests, time-shifting requests, and so forth. The header does not work hard enough. This is increasing development time and making testing more challenging than necessary, both of which cause seller confusion. The only answer to solving this issue right now is increasing the limit or ditching the API for orders/order items.

Requesting an increase is a function of the observations of the API behavior, and the header is a diagnostic documented by Amazon when making a limit increase request. Since header enhancements are unlikely, which is what your request is, it is reasonable to ask Amazon "in the absence of those requested enhancements, who is responsible for a request to have limits increase, and what boundaries/thresholds must be met?" . I provided an actual use case as a point of reference. Maybe at those volumes, we should not need a limit increase. Maybe those volumes meet a threshold. As it stands, using the header as is does not offer the context needed.

[johnkw]

Thanks -- please move that unrelated content to a new ticket so as to not confuse people wondering about whether or not the x-amzn-RateLimit-Limit works.

[franclin]

Hi @tspicer @johnkw Just to follow up on this issue. I agree that the rate limits are particularly useless when it comes to GetOrder and GetOrderItems requests. Would it be easier to just sleep for x-amzn-RateLimit-Limit seconds every time we make a call to GetOrderItems?

[johnkw]

The x-amzn-RateLimit-Limit header isn't even returned reliably. Right now what we're doing is maintaining an internal list of calls, and what their documented limits are, and we sleep according to those documented numbers, which seems to generally work (though mysteriously it sometimes fails, I suspect due to some AWS machine having a broken clock or something).

('POST','/reports/2021-06-30/reports'): (0.0167,15),
('GET', '/reports/2021-06-30/reports'): (0.0222,10),

[franclin]

The x-amzn-RateLimit-Limit header isn't even returned reliably. Right now what we're doing is maintaining an internal list of calls, and what their documented limits are, and we sleep according to those documented numbers, which seems to generally work (though mysteriously it sometimes fails, I suspect due to some AWS machine having a broken clock or something).

('POST','/reports/2021-06-30/reports'): (0.0167,15),
('GET', '/reports/2021-06-30/reports'): (0.0222,10),

Thanks for the tips @johnkw. So, essentially for GET requests to reports to you would sleep for how many seconds? 1? given that 0.0222 isn't an integer? Also what does the second parameter do?

[johnkw]

This ticket should not be closed @shreeharsh-a

[shreeharsh-a]

Please reach out to developer support so that we can better help you with issues related to SP API.

Note: SP API related issues / troubleshooting support is managed by a different team. We can help if the issue is related to the content published on this repo.

[johnkw]

It would be helpful to leave the bug open until it's fixed, so people know where to look for information on this bug.