Thanks for the very detailed report. We should investigate on Monday @oldbonsai
A fix is now live. Can you check to see if it the behavior is corrected?
Looks all good to me. Thanks very much for fixing it so soon!
I am looking to import users learned vocab from Wanikani so they will be excluded from an automated Furigana tool. I see the v1 docs look good. https://www.wanikani.com/api
It is very hard to search this entire thread for examples of the endpoint.
In a CURL request (or requests) how would I get a users learned vocab?
A few CURL examples would be very helpful.
This is exactly what I want but it is V1. I do not want to get sun setted on
I’m not at my computer, so I can’t do a sample curl request. But all you really need is something like this as a template:
curl 'https://api.wanikani.com/v2/subjects' -H "Authorization: Bearer your_apiv2_key_here"
/v2/subjects contains item info, and
/v2/assignments contains the user’s status for each of those items. The records returned by those two endpoints are linked by their corresponding
Since both of those endpoints are paginated (i.e. only 1000 records at a time), you’ll need to look at the
pages.next_url field for the url to read the next 1000 items.
EDIT: If you plan to get incremental updates, you’ll need to learn to use the
updated_after parameter in the URL.
Awesome. That will work! Looking forward to the docs that have those bits. Saw the one Github repo from v2 docs that may need updating from people on here. Thanks again!
Sounds similar to something I have been working on, but I just hardcoded each level for now.
Not sure about that. Mine allows users to exclude words they learned from any site with mouseover/hotkey, also restrict generation of Furigana by JLPT level. Still doing beta
Suggestion: With the recent overhaul of content, it would be very helpful if the payload in the
GET /users response included a boolean property indicating whether the user has configured their profile to display the old mnemonics or not.
Is there any chance that v2 will allow write access for a limited number of settings?
I can’t honestly think of many examples where this would be useful, but the one that does come immediately to mind is being able to set vacation mode from an app, versus having to log on to the site to do it.
Write access is dangerous because then users have to worry about apps/scripts modifying their account. I think at that point you’d need a second key that allows write access, at the absolute minimum. And that wouldn’t make it much more secure.
Heya, would you mind updating the top-level post with the current state of the API? I developed against the original post schema, and this has bitten me. I know it isn’t realistic to update the schema constantly, but it would be great if you either had:
- Some autogenerated API docs(swagger, coreapi)based on the state of the V2 API.
- The occasional update to the top-level post here, for newcomers who want to develop without reading through 500+ posts to find the little gotchas where things don’t perfectly line up.
Thanks for the hard work!
Howdy everyone. I’m working on a personal project that’s using API V2 (I initially wrote it using V1, but decided we might as well get the conversion done now since it’s a personal project and not being distributed).
Anyways, I notice when I pull a subject that we only have images and SVGs in black (as opposed to white for V1) for the subjects that lack a unicode character, and was curious if anyone had a good approach to overcoming this Do you fall back to V1? Grab the SVG and style it? Should I just be patient and wait for white variants of the PNGs?
Thanks in advance!
You can use the SVGs without styling, then add your own CSS. That’s what I do on wkstats.com:10001.
Or put a stronger CSS rule to override the default stroke color.
I popped up my account and inspected the radicals in Chrome, and that does look like a good approach. I’ll make note to try something similar.
Thanks for the speedy reply!
Just want to give a heads up on changes we will be releasing on Monday.
- We have started a WaniKani API mailing list. This is for new, announcements, and updates in regards to the WaniKani API. The mailing list can be found here.
- Subjects (Radical, Kanji, Vocabulary) payloads are going to include all the WaniKani content such as the mnemonics, pronunciation audio, context sentences, et cetera. The current structure and attributes will remain the same, but they’ll now be additional attributes to cover the additions. I recommend you all review the Terms of Service, especially the API section. If you have a public application please respect the subscription restrictions. You all can now stop scraping our website
- Speaking of adding our content to the Subject payloads we have finished recording and editing new audio for all vocabulary in our system. This content will be live only in API v2 for now. We plan on replacing the old audio currently being delivered on the web app with the new audio in the near future. The new audio is a native male speaker (with a less pronounced Tokyo accent). We are finishing up the native female speaker and will include her pronunciations. In the end there will be a set of male audio and female audio.
/userendpoint payload will be going through a breaking change due to a restructuring. It will not break on Monday’s update. We will maintain the old attributes and include the new structure. Eventually we will drop the old attributes. The change is in regards to the information we return concerning the user’s subscription status. Attributes
subscribedWill be consolidated in a nested object, thus will be dropped. Please review the API v2 doc mentioned in item 5 for the new structure.
- We have published API v2 docs that is current with Monday’s update. You can find it here. This will replace the documentation in this topics original post going forward.
- With this update we are moving from alpha to beta for API v2. We have one breaking change and following that will be adding additional HTTP methods to existing endpoints.
WaniKani Weekly Updates