#Limitations and Requirements
MangaDex is a non-profit service operating with limited infrastructure resources.
To ensure the continued stability of our platform and combat abuse, we enforce a handful of restrictions on incoming request rate on an IP-by-IP basis. Hence, if you're on a VPN, proxy or a shared network in general, the requests of other users on this network might affect your allowance.
#General connection requirements
MangaDex supports HTTP/1.1, HTTP/2, and HTTP/3 over QUIC, and requires the usage of SSL/TLS for all of these.
MangaDex requires that your browser/client supports the following specifications.
The TLS Server Name Indication extension for the following protocols:
- TLSv1.2 (deprecated for removal at a later date)
- TLSv1.3
Insecure/plain-text requests will systematically result in an HTTP 30x redirection to the secure equivalent of the URL reached.
You may find a more detailed report on SSLLabs.
Additionally, the following requirements are placed on incoming HTTP requests:
- The request MUST have a
User-Agentheader, and it must not be spoofed - The request CANNOT have a
Viaheader (i.e.: we do not allow non-transparent proxies)
The following anti-abuse policies are in place:
- We do not send CORS responses for other websites than ours; MUST proxy the requests your users make to our services, and inject your own CORS responses and headers where relevant
- We will serve the wrong response for any image hotlinked from our domains; you MUST proxy the requests your users make to our services
Finally, an undocumented handful of IPv4 subnets are banned forever from reaching us.
#General rate limit
A global limit of approximately 5 requests per second per IP address is in effect for api.mangadex.org as a whole (and its development counterpart, api.mangadex.dev, independently).
This is not an exact value but a minimum guaranteed allowance. Your effective allowed rate may be higher for various reasons (notably that we enforce it at the load balancer level, so if you reach 2 load balancers of ours perfectly equitably, you would get 10 requests/s. This is not something you can reliably control.)
Once above this rate limit, you will receive HTTP 429 responses for all requests to *.mangadex.org until enough time has passed to bring your rate back in line.
If you persist in sending requests while receiving HTTP 429 responses, our DDoS protection will automatically be triggered and you will be issued a temporary IP address ban, resulting in a generic HTTP 403 response for all requests to *.mangadex.org. Its duration is not documented and subject to change without notice.
If you still persist in sending requests at that point, we will automatically stop replying to your IP address altogether until we stop receiving traffic from you for a while. This cooldown period is renewed for every request you send while still blocked. Its duration is not documented and subject to change without notice.
Unfortunately, we regularly see particularly abusive request patterns from clients that are just too lazy/disrespectful to use our API decently. If you wonder whether your usage falls in this category, it probably doesn't. And offenders are nearly always well-aware of it.
TL;DR: If you decide to do 500 requests where the same exact feature is implementable with 1 single request, we will drastically throttle you, or block it altogether. The reduced rate and the patterns affected are not documented and subject to change without notice.
We enforce rate limits on all of our public services; this page documents only the ones for api.mangadex.org specifically. These other rate limits are for DDoS protection and you will not hit them if you aren't trying to DoS us. They are not documented and subject to change without notice.
#Endpoint-specific rate limits
On top of this general limit, some endpoints are further restricted as follows, primarily to combat spam and/or mistaken API usage.
Most use-cases are highly unlikely to hit them in normal usage, since they mainly relate to data modification rather than consumption.
Calling these endpoints will provide extra details via the following response headers:
#Collection result sizes
Endpoints returning a collection of elements (such as the searches and feeds endpoints), typically take an offset and a size query parameters.
- Requests where
offset + size > 10.000will be rejected. - The
sizequery parameter will typically not allow values greater than100(500for a handful of feed endpoints); you must instead use multiple requests with changingoffsets to paginate through large responses.
This is for performance reasons and will not change.