Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

missing headers for X-MBX-USED-WEIGHT and Retry-After #56

Open
avnerbarr opened this issue Feb 1, 2024 · 3 comments
Open

missing headers for X-MBX-USED-WEIGHT and Retry-After #56

avnerbarr opened this issue Feb 1, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@avnerbarr
Copy link

the documentation states:

https://binance-docs.github.io/apidocs/spot/en/#limits

IP Limits

Every request will contain X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter) in the response headers which has the current used weight for the IP for all request rate limiters defined.
Each route has a weight which determines for the number of requests each endpoint counts for. Heavier endpoints and endpoints that do operations on multiple symbols will have a heavier weight.
When a 429 is received, it's your obligation as an API to back off and not spam the API.
Repeatedly violating rate limits and/or failing to back off after receiving 429s will result in an automated IP ban (HTTP status 418).
IP bans are tracked and scale in duration for repeat offenders, from 2 minutes to 3 days.
A Retry-After header is sent with a 418 or 429 responses and will give the number of seconds required to wait, in the case of a 429, to prevent a ban, or, in the case of a 418, until the ban is over.
The limits on the API are based on the IPs, not the API keys.


but when generating the code these headers are missing since not in the spec

@aisling-2
Copy link
Contributor

Hi, the swagger doesn't contain response headers. What's truly important is the response body. The response headers have little variation across responses, they're only different when dealing with an order request from regular requests and when the request is to a /api/ endpoint or a /sapi/ endpoint. Nether less, it's something we can explore adding in the future, so tagging this as enhancement.

@aisling-2 aisling-2 added the enhancement New feature or request label Feb 2, 2024
@avnerbarr
Copy link
Author

This is basic. Everything that is documented in the website has to be accounted for in the API spec document. I don't want to imagine what else could be missing while developers are relying on this basic API spec

@maciek75
Copy link

Adobe Scan 15 maj 2024 (1).pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants