Wanikani Open Framework [developer thread]

Yeah, just wanted to make sure. But I guess it’s not really important either way.

うわー 皆、皆、見たの?Kumirei先輩は私にまた気づいた!


I don’t know if it’s possible but is there a way to get only kanji reviews? The type of the object is not a data point of the review data so there is no query parameter for kanji (like there is in subjects for example).

Though I did try to first get all the kanji item ids through filtering the subjects data point and putting them all into a list. That list can then be fed into the “subject_ids” filter for reviews which should do the trick (only getting reviews with subject ids of kanji). But then a CORS policy error occurred. Probably because the url was too long. It is over 8000 characters long due to how many kanji there are in WK (~ 2000). But I don’t really understand when or why the CORS policy takes effect or if it has something to do with the device I’m using (I tried it on multiple browsers).

This is the main part of the code:

var reviewOptions = { filters: { subject_ids: allKanjiIds } };
await wkof.Apiv2.fetch_endpoint('reviews', reviewOptions).then(data => { reviewData = Object.values(data); });

Where allKanjiIds is just a list of integers containing all the kanji ids.

So my question is: Is there a way to fix this so that the CORS policy does not randomly intervene only because the url is too long. Or is there a different way to filter out only the reviews which involve kanji?

It’s not that big a problem because I can just filter them out after fetching all the review data but that can take ages for long time users so I would like to make it faster and not download unnecessary data.

P.S. I understand that this may not be a problem with wkof but I just wanted to ask you for advice because you may have encountered the problem before or something… :sweat_smile: Although I could not find a comment in this thread discussing the fetching of kanji-only review data.

Edit: Should I maybe fetch review data for like 5 subject ids at a time or is that gonna take longer? It will probably take more API calls too…

Sounds like you have a pretty good grasp of the options and limitations. The best I can suggest is to cache the /reviews data so it will only take a long time once.

1 Like

Ok, thank you! It’s not even that this is that important an issue. I just wanted to make sure that I haven’t overlooked anything.

Edit: It works in batches of 1000 ids each. I might have to look into if this holds for all devices though but I might get away with three wkof calls!
Might not be good practice but oh well, if it works it works.


WKOF still can’t seem to quite get to the end of my reviews, which means I can’t use the Heatmap or the stats sites. I’ve waited it out for a week or two, but still nothing… :frowning:

1 Like

If you’d like, send me your API key and I’ll see what I can figure out and/or do.


API key sent.

As stated in the email, please let me know if you need more privileges than the standard read-only token.

1 Like

@UInt2048, are you still having problems?

I was able to load your data on wkstats, though it took about 6 seconds before the review_statistics started loading.

Also, I just tested Heatmap. It took probably 15 seconds or so before reviews even started loading. And then it paused for 30sec or more about 2/3 of the way through due to too many requests. But it resumed, and was able to load everything eventually.

Note: I did this at about 0800 UTC (4am New York time). I know the server load is lighter at that time, but I’m not sure if that could affect this specific issue.


I have been able to reach the WK History website today, at 2022-06-30T13:00:00Z.

Hopefully I don’t experience more issues but I can’t test Heatmap for a while…