Wow, impressive. That’s WAY above my skill level 
That last graph is super-cool and almost what I was thinking, but incoming reviews due in the future instead of items done. I’m imagining I would get something like the same graph flipped right/left and the colors all reversed. A big stack of apprentice items coming from not too far away, a longer stream of guru, longer still of master, etc. It would look like a tsunami building up to shore.
Well done!
Ah I see! My mistake 
I’ll think on that and see if I can’t whip up something. That would be useful for me as well.
All my v2 API requests started returning 404 a few weeks ago after working properly for many months and I have no idea why. Even trying the example in API V2 Beta Documentation - #279 by viet doesn’t work.
I tried resetting my key today but that didn’t help.
Is v2 still supported?
My v1 requests still work fine, but v1 doesn’t support what I need.
Can you give a CURL example of a failed called?
V2 is still active. We are getting solid levels of 200 traffic.
the following CURL works just fine for me.:
curl -X GET "https://api.wanikani.com/v2/user" -H "accept: application/json"
It returns a 401 error, but that’s expected without an access token.
I have interactive documentation here that you can try:
https://bennettbuckley.github.io/
EDIT: @viet, I’ve noticed that you don’t have the srs_stages endpoint listed in the first post.
curl "https://api.wanikani.com/v2/user" \
-H 'Authorization: Bearer xxx'
I am using the above with your API v2 key @richcatalano (starts with f ends with d). I am getting a 200 response. Can you try the snippet above with your key?
Added. Thanks!
For what it’s worth, my Google sheets script using v2 also stopped working the sixth or seventh of september, but I’ve been too lazy to figure out why.
@finnra and @richcatalano: Last week we took down the old API v2 paths, per this PSA. In your code, do a search for /api/v2 and see if any of your URLs are affected.
Why the delay, you ask? We put them back up to keep to help out a few folks taken by surprise and negatively impacted, then forgot to take them down again. 
Hi, I got something working which might help me with my stuff. Like, export the Kanjis to an Anki compatible format which I need to learn.
I wonder how I could find my leeches with this API. Any idea?
Thanks
You might try using the review_statistics endpoint to get your correct/incorrect counts for each subject (the below is restricted to just kanji):
curl -X GET "https://api.wanikani.com/v2/review_statistics?subject_types=kanji" \
-H "accept: application/json" \
-H "Authorization: Bearer your-key-here"
Calculate your leech factor however you like, and record the ids for the ones you decide are leeches. Then you can use the subjects endpoint to get all your leech subjects:
curl -X GET "https://api.wanikani.com/v2/subjects?ids=457%2C1656%2C2257" \
-H "accept: application/json" \
-H "Authorization: Bearer your-key-here"
https://wanikanitoanki.com does not download leeches, as determined by the formula used by @seanblue, @StellaTerra, @hitechbunny et al. However, the Anki card layout might be useful to you.
Thanks. I actually looked into it, but found the cards no to suit my taste. In example, I could only chose to have one field on front and one on back. I. e. Kanji front, onyomi back. I could not have kunyomi if its the preferred reading.
So I wrote my own exporter which now combines the meanings, various readings on the back of the card.
Thanks, that’s a good start for me.
Thanks again wunderbunny, I found the formula by @StellaTerra very helpful. I was able to create some script for the CLI to create a leech.csv ready to import to Anki. I will create another thread for it.
Well, it took a bit, but we’ve got an id field on the user payload that delivers a UUID. Enjoy the odds of finding a duplicate (from Wikipedia): “the probability to find a duplicate within 103 trillion version 4 UUIDs is one in a billion”. (Note that we don’t have 103 trillion users.)
And while I’m here talking about changes, we’ve got one that’s going up on Monday: we’re dropping the level field from the assignments payload. That could be a biggy for some folks, so make sure your code still works without that field. The level filter on the assignments endpoint will still work, though.
If you’re wondering why, it has to do with our general move towards more independent and resilient objects in API v2.
Assignments have a subject, which belongs to a level. We want to make that relationship only exist once and make it clear when that relationship changes. By having the level field in the assignments, we have to either maintain that data in the millions of assignments out there (boy, does that suck to update when a subject moves around) and/or cache bust all the assignments delivered through the API when a related record changes.
Dropping it means we update a subject’s level, mark it as updated, bust the cache on that one record, and call it good. For y’all (and us internally), it does mean checking on those subjects periodically, but that has to happen anyway when a subject level changes.
TL:DR; we’re breaking things on Monday. 
I assume that also means that query filter will be gone as well?
Nope, the query filter for level will remain.
Hooray for joins then!