API V2 Beta Documentation

Your API tokens can be found at WaniKani — Log in

3 Likes

API Version 1 and API Version 2 keys exist separately. @bladepoint post with the link directs you to the page where the keys are listed.

I also recommend generating a new API V1 key since you have publicly shared the key here. It isn’t advised to do so.

2 Likes

@viet, you hid 今日は, I mean forbidden item 7564, which is still showing up for subject 476 (日). Can you please fix this? I preferred it when it was working. :cry:

Don’t we always prefer when everything is working?

Lol. Viet is fixing this issue, but this means that 今日は, oops I meant 七千五百六十四, won’t be taught on WK. Please file a complaint (but not to Viet, it’s not his fault) if you object to this.

Just to follow up on this for those coming in on this conversation.

See the conversation over at Github for context on the issue with the API payload returning stale data.

For subject id 7564 on the reason for why it was removed please see the post for context.

As far as the stale data is concerned it is resolved now.

1 Like

Thank you guys, I have learnt a big lesson. I now understand how the API token works.
Unfortunately You Guys don’t know just how much I don"t know!!!(shame). When I read the forums I glean a small amount of knowleDge which can be quite dangerous…
API TOKEN NOW REPLACED AND FUNCTIONING. Thanks for your tolerance. YOUR KNOWLEDGE IS GREAT

2 Likes

Hello all,

The removal of the old subscription fields in the GET /user payload is now live.

You can view this pull request on the API documentation to get an idea of what was removed and where the equivalent details are located.

2 Likes

Thanks for this @viet. One thing though: it would be good to have the documentation up-to-date. I got bitten a couple of times although a quick curl call showed me what was right/wrong.

Actually, checking the documentation for user, it seems fine. So, all I know is that, at some point, there was some discrepancy (and maybe there still is) between the documentation and the actual API.

Can you point where it has been outdated? Just asking because we are always looking to improve the process.

We try and have the doc reflect what is being currently delivered on the API. Any upcoming changes we have a PR up on the doc repo. We try and have this up ahead of time. And then we do a heads up announcement here and via the API mailing list, communicating the changes and pointing to the PR.

Once the changes are live we merged in the doc PRs and notify everyone here and the mailing list.

Appreciate the feedback.

2 Likes

Ok, I just had a very, very quick look and the documentation does seem to mention the different fields I am seeing in the JSON responses.

However, in the examples, I noticed one omission for Assignments and a different order for User:

  • Assignments: the data misses the hidden field. It is present in the documentation itself, but not in the example (be it for a specific assignment or all assignments).
  • User: the order in which some fields are listed is not the same in the example and in the JSON response (current_vacation_started_at and the preferences data). This is clearly not critical, but I thought I would still mention it.

I honestly can’t recall whether I had noticed more differences last time I checked (several weeks ago), but I am now wondering whether I might not have been misled by the examples (rather than the documentation itself).

Indeed, I remember initially using the examples to automatically generate some JSON converters (using https://quicktype.io/, a pretty nifty tool!) and might have then decided to rely on calls to curl to get a “proper” idea of the kind of JSON response I might expect. However, this didn’t prove to be the perfect solution since some fields can be null.

Anyway, if anything, it would be nice to have fully populated JSON responses for the different endpoints. Indeed, to have values that are null means that tools like https://quicktype.io/ can’t generate a suitable converter.

1 Like

@viet - please correct ‘嘘’ relation with ‘spikes’ and ‘cactus’ - in API schema ‘cactus’ lists ‘嘘’ as an amalgamation, but it is not listed as a component (points to ‘spikes’ instead, which does not list it in its amalgamations).

The data has been corrected. One of our pieces of cached data got out of sync with some recent content changes. We’ll dig into the source of the problem and make sure it doesn’t continue with future updates.

1 Like

Oh, man. So, we fixed this problem and deployed it the day after the edit was made. :man_facepalming: It’s fixed, though, and shouldn’t pop up again.

3 Likes

I want to get into coding things using this API, but honestly I have no idea where to start. I have taken some basic programming courses in university but I’ve never come across an API before. Does anyone have an “API for complete beginners” post or something I could follow along with just to get my bearings?

I also noticed that the version is “Revision 20170710” does that mean apiV2 hasn’t been updated since 2017?

If you want to make a script you could just have a look at existing scripts and it should be easy enough to get started. Otherwise how you access the API will depend on your language. The specific term you might want to google is GET requests to start with. You’ll need to request a URL and include some headers including information such as your API key. In the docs you can see examples using cURL, which I think should work in most terminals.

It doesn’t, they just don’t version the API during its alpha phase since breaking changes are inherent to alphas.

2 Likes

So I’m looking at the Assignment data structure.

Assignments are created when a user has passed all the components of the given subject and the assignment is at or below their current level for the first time.

So I interpret this in the context of kanji as if I’ve passed all radicals that compose the kanji then the kanji assignment is created.

Looking at the unlocked field on the assignment struct, I can’t figure out the intention for this field.

unlocked_at: The timestamp when the related subject has its prerequisites satisfied and is made available in lessons.

So this makes me think if I have a kanji at the current level that isn’t unlocked then an assignment should exist but the unlocked_at field would be null.

This isn’t the behavior as far as I can tell, so what are the use cases around this field?

My use case:
For the max level achieved, give me all possible kanji assignments regardless of whether they are unlocked.

My goal:
Determine the srs stages of all subjects of type kanji at a certain level.

What it seems like I have to do is:

  1. get all subjects at the level of interest of type kanji
  2. get all assignments at the level of interest of type kanji
  3. cross reference kanji, if a kanji DNE in assignments, assume SRS level 0

(I know this is question is only partially related to the API docs, so if I need to ask this elsewhere please let me know)

You can’t have a locked item with an assignment since it will unlock only when the components of the subject are passed, right?

1 Like

You can’t have a locked item with an assignment since it will unlock only when the components of the subject are passed, right?

An assignment is created when a user has passed all the components of the given subject AND the assignment is at or below their current level for the first time.

So when querying /assignments?unlocked=false&levels=<value greater than my current level> I should expect no results if I’ve never been that level before ?

I’m confused with the results I’m seeing as I’ve never been above level 17 and I have assignments at levels that I have not unlocked. Why would those assignments have been created?

1 Like

Sometimes they move items between levels, so if an assignment was created for a subject and they then moved it, then you would have an assignment for a technically locked item.

2 Likes