Jikan in 2026: What the Unofficial MyAnimeList API Can Do, and the One Thing Only the Official API Can

A developer building an anime tracker told me he lost a full day to OAuth before writing a single feature. He'd searched "MyAnimeList API," landed on the official developer docs, registered an application, wired up the OAuth2 authorization-code flow with redirect URIs and token refresh, and finally got an access token. Then he used it to do the only thing his MVP actually needed on day one: show the synopsis, score, and cover art for a given anime. Every one of those fields is public. He had built an entire login dance to fetch data that no login protects.

There are two MyAnimeList APIs, and almost nobody tells you that the choice between them has nothing to do with which is better. Jikan, the unofficial one, and the official MyAnimeList API v2, the OAuth2 one, split cleanly along a line most tutorials never draw: does your feature touch a specific user's own account? Public anime facts on one side, a logged-in user's personal list on the other. Get that line right and the rest of the decision makes itself.

The two APIs, on one screen

These are not two flavors of the same product. They are two different services solving two different halves of the problem.

The row that decides everything is "writes to a user's list." Jikan has a hard No there, and no amount of cleverness changes it. The official API has the only Yes. Everything else is a matter of convenience.

What Jikan actually is

Jikan is an open-source REST API that reads public data from MyAnimeList.net and re-serves it as clean JSON. The name comes from the Japanese word for "time," and the project exists for one reason: for years MyAnimeList had no usable public API, so the community built one by reading the site and exposing the result. Today it runs as a PHP/Laravel application, the current version is v4, and the public instance lives at https://api.jikan.moe/v4.

The headline feature is that there is no friction. No API key, no account, no OAuth, no Authorization header. You send a GET request and you get JSON. This works right now, from your terminal, with nothing set up:

curl "https://api.jikan.moe/v4/anime/1"

That returns the full record for Cowboy Bebop: titles in multiple languages, synopsis, score, rank, episode count, airing dates, studios, genres, and more. The endpoint surface is broad and maps onto how people actually browse anime: /anime and /manga for search and detail, /characters and /people for cast and staff, /seasons/now for the current season's lineup, /schedules for what airs on each weekday, /top/anime for rankings, /genres/anime for genre filtering, /producers for studios, plus /random, /recommendations, and /reviews. For a browse-and-discover product, that covers essentially everything you'd want to show.

What Jikan is not is a live mirror or a write surface. It reads public pages, so it cannot see anything private, and it cannot authenticate as anyone. That single property is the source of both its biggest advantage (you need nothing to use it) and its one hard limit (it can never touch a user's account).

Rate limits and the 24-hour cache you need to design around

The public Jikan instance enforces two limits simultaneously: 3 requests per second and 60 requests per minute. Both apply, so a burst of 5 requests in one second trips the per-second limit even if you're nowhere near 60 in the minute. Exceed either and you get HTTP 429. There is no published daily cap, but treating the per-minute ceiling as your real budget is the right mental model. (If you find old code or tutorials assuming 30 per minute, that's v3, which is deprecated; v4 doubled it to 60.)

The second thing to design around is freshness. Jikan serves cached data, with a default cache lifetime of 24 hours (CACHE_DEFAULT_EXPIRE=86400 in the configuration, with some endpoints setting their own shorter expiry). For 95% of what people build, this is invisible and good: anime synopses, scores, and cast lists barely change, and the cache is what lets a free, donation-funded service stay up. But it means Jikan is the wrong tool for anything that needs to-the-minute accuracy. A brand-new score on an episode that aired an hour ago, or a list a user edited thirty seconds ago, will not be reflected immediately. If your feature's value depends on real-time data, that's a signal you're on the wrong API for that feature.

These two facts combine into a clear usage pattern: cache Jikan responses on your own side, key requests so you don't refetch the same anime repeatedly, and stay well under 60/minute. The project is donation-funded and asks you to be considerate rather than charging you, so aggressive client-side caching isn't just good for your latency, it's the implicit deal.

The official MAL API v2: the only one that can write

The official API is what you register for at MyAnimeList's developer settings, and it differs from Jikan in two ways that matter. First, even reading public data requires identifying your app: you register an application, receive a Client ID, and send it as an X-MAL-CLIENT-ID header. Miss that header and public reads fail with an unauthorized error. Second, anything that involves a specific user (reading their list, updating their watch status, changing a score) requires the full OAuth2 authorization-code flow, where the user logs in and grants your app permission, and you receive an access token scoped to that user.

That OAuth2 path is the entire reason the official API exists for most developers. It is the only way to:

• Read a logged-in user's anime or manga list, including private entries
• Update the user's status (watching, completed, on-hold, dropped, plan-to-watch)
• Set or change the user's score on a title
• Add or remove entries from the user's list

Jikan cannot do any of those, by design. So if you're building anything where users sign in with their MyAnimeList account and your app reads or modifies their personal list, the official API isn't optional, no matter how much nicer Jikan is to call.

The trade-off is real friction. You go from "send a GET request" to "register an app, implement OAuth2, handle redirect URIs, store and refresh tokens, manage per-user scopes." That's a meaningful amount of work, and it's wasted work if your feature never actually touches a user's account, which brings us back to the opening developer's lost day.

So which do you pick?

The decision collapses to one question, and you should answer it feature by feature, not once for the whole app.

Does this feature touch a specific user's own MyAnimeList account?

If no (search, anime and manga detail pages, seasonal charts, top-100 rankings, character and staff pages, genre browsing, "what airs on Tuesdays"), use Jikan. There is no reason to take on OAuth2 and app registration to display data that no login protects. Zero auth, full public catalog, done.

If yes (a logged-in user's personal list, their scores, marking something as watched, syncing their plan-to-watch), use the official API v2 with OAuth2. Only it can authenticate as that user, so there's no alternative.

And the answer for a lot of real apps is "both." A typical anime tracker uses Jikan for the entire public catalog (so users can search and browse a deep, rich dataset without you ever provisioning a key) and the official API only for the thin slice where a signed-in user reads and edits their own list. You get Jikan's frictionless breadth for the 90% that's public and pay the OAuth2 cost only for the 10% that genuinely needs it.

When 60 requests a minute isn't enough: self-hosting Jikan

If your public-data needs outgrow the shared instance's 60/minute, you don't switch APIs, you run your own Jikan. The whole thing is open source (jikan-me/jikan-rest) and ships as a container image:

docker run -d --name jikan-rest -p 8080:8080 \
  -v ./.env:/app/.env jikanme/jikan-rest:latest

A complete self-host is more than one container, though. The service wants a web server, scheduled tasks, and queue workers for its caching and search indexing, plus a cache backend (it supports Redis and file caching, with the 24-hour default expiry configurable via CACHE_DEFAULT_EXPIRE), and optionally MongoDB. A docker-compose setup wiring those together is the realistic path. The payoff is that you set your own rate limits and your latency is your own, while still hitting the same MyAnimeList data. Self-hosting changes nothing about the read-only nature: a self-hosted Jikan still cannot write to a user's list, because it still has no user authentication. Throughput is the only thing self-hosting buys you.

Wiring it up: the request for each

Jikan, no auth, just a GET:

curl "https://api.jikan.moe/v4/anime?q=frieren&limit=5"

The official API, reading public data, needs your registered Client ID:

curl "https://api.myanimelist.net/v2/anime?q=frieren&limit=5" \
  -H "X-MAL-CLIENT-ID: YOUR_CLIENT_ID"

The official API, reading the signed-in user's own list, needs the OAuth2 access token you obtained after the user granted permission:

curl "https://api.myanimelist.net/v2/users/@me/animelist?status=watching" \
  -H "Authorization: Bearer USER_ACCESS_TOKEN"

The shape of these three lines is the whole article in miniature. The first needs nothing. The second needs you to have registered. The third needs a real human to have logged in and said yes.

Before you ship

A short checklist for integrating MyAnimeList data, from prototype to production:

1. Split your features by the "user's own account" line first. List every feature, mark each as public-data or user-account, and you'll see immediately which need Jikan and which need the official OAuth2 API. Most trackers land mostly on the Jikan side.

2. Don't build OAuth2 for public data. If a feature only displays anime and manga that anyone can see without logging in, Jikan removes the entire auth problem. Reserve OAuth2 for the features that genuinely read or write a user's list.

3. Cache Jikan responses on your side and throttle to 60/minute. The 3-req/sec and 60-req/min limits are real, and the service is donation-funded. Cache by resource ID so you don't refetch the same anime, and you'll rarely see a 429.

4. Treat Jikan data as up to 24 hours stale. It's served from cache. That's fine for synopses and rankings; it's wrong for anything needing real-time accuracy. If you need live, that feature belongs on the official API.

5. If you outgrow the public instance, self-host before you re-architect. jikan-rest is open source and Dockerized. Running your own copy lifts the rate limit without changing a line of your client code, but remember it's still read-only.

For a side-by-side of what each MyAnimeList API exposes and its current limits, the Jikan tool page and the official MyAnimeList API page hold the version-current summaries. For adjacent catalog and entertainment-data services, the media category lists the rest of the directory.