Jikan turns MyAnimeList into a keyless REST API, rate limit and all

What it covers

Jikan sits in front of MyAnimeList, the site itself has no public API, and re-serves its anime, manga, character, and season data as plain JSON. A live GET https://api.jikan.moe/v4/top/anime?limit=3 this session returned pagination.items.total: 30729, the full size of the ranked anime list behind that one endpoint. A search for naruto came back with 30 matching entries, and looking up id 20 directly returned the Naruto record with cover art URLs on MyAnimeList's own CDN.

The project publishes its own OpenAPI description (v4.0.0, OpenAPI 3.0.0, one server at api.jikan.moe/v4) with 100 documented paths. Three of them cover the hero endpoints this catalogue entry lists: GET /anime, GET /anime/{id}, and GET /top/anime, all confirmed live this session.

Auth and pricing, as they actually work

No key, no login, nothing to configure. Every call in this session went out anonymous and returned real data, matching the auth: None already on file. Only GET is exposed; since Jikan can't write back to MyAnimeList, there's no authenticated tier to gate behind a key in the first place.

There's no paid plan either. The project's own OpenAPI description lists Patreon as the way to support it, not as a way to unlock a higher limit. Because Jikan is scraping MyAnimeList rather than querying a database it owns, its docs also warn that a request can still get rate limited by MyAnimeList itself on the way through, on top of whatever ceiling Jikan applies at its own edge.

Rate limits and CORS, confirmed live

Jikan's OpenAPI description states the limit outright: 3 requests per second, 60 per minute, unlimited per day. Eight rapid identical search calls this session got two genuine 429 responses, with the rest coming back as 504s from Jikan's own upstream instead of a clean 200, a sign the limiter and the MyAnimeList scrape both strain under a fast burst. That's a limit you can actually hit, confirmed live rather than taken from the docs on faith.

Every response also carried access-control-allow-origin: *, so a browser can call this straight from client-side JavaScript. Caching runs for 24 hours per the docs; the /anime/20 response came back with cache-control: public, s-maxage=86400, matching last-modified and expires headers, and an x-request-fingerprint header that the docs say only appears on single-resource lookups like this one, not on search or listing endpoints such as /anime or /top/anime, and that held up: the search response carried no such header.

Why it's worth a look

MyAnimeList has no public API of its own, so anyone building an anime tracker or a Discord bot would otherwise be stuck scraping the site by hand. Jikan already did that work and put a key-free JSON endpoint in front of it. Once a client has the mal_id, an anime's characters, staff, and episodes are all reachable from it, so there's rarely a need for a second data source.

The tradeoff is that Jikan is a small, community-run proxy sitting between a client and a site it doesn't control, so an outage on MyAnimeList's end shows up as a 504 through Jikan rather than a clean error from the API itself, exactly what several calls in this session ran into. Anyone caching responses locally, as the 24-hour cache headers already invite, avoids most of that friction along with the rate limit.