API V2 Beta Documentation

Everything looks like it’s working to me.

Made a.Net library for the latest API out of the code I’m using for my client. All of the queries listed in the official documentation should work, but I haven’t unit tested everything, so don’t quote me on this.

Thanks to @Doublevil for his github project, I took some inspiration from his work.

Is there a way to check if the token is valid before trying to fetch the resources we want?
All i need is a 200 HTTP ACCEPTED response and i wouldn’t want to wight it by asking for anything else like user profile

1 Like

Hi,

I have just gone back to WK after some time, and decided to reset my account and found out about version 2 of the API. So, I thought I would update my small WK-related application software that currently relies on the original API.

Good news is that I am able to retrieve some information using version 2 of the API. However, the bad news is that there seems to be quite a few things that have been removed? For example, I need/want to retrieve the gravatar and title information that is available using the original API, but that information doesn’t seem to exist in version 2?

So, I was wondering whether there is some kind of documentation that shows what is different between the original version and version 2, e.g. what has been added/removed (and maybe some quick rationale for what has been removed?), as well as how to now do this or that using version 2 rather than the original version.

Cheers, Alan.

1 Like

Welcome back to the forums!

I am having some issues with the API endpoints for creating reviews and starting assignments, and I am not sure if what I am seeing is a bug or just a misunderstanding of intended behaviour.

If I start an assignment after completing a lesson, while specifying a started_at date (offline mode), then the next available_at date is different from what I expect. The started_at date is correctly recorded in the assignment, but the available_at seems to be calculated based on the time of the request, not the started_at time:

Mon Sep 02 10:42:09 GMT+02:00 2019 ReportSessionItemTask Posting: https://api.wanikani.com/v2/assignments/126587412/start
Mon Sep 02 10:42:09 GMT+02:00 2019 ReportSessionItemTask Request body: {
  "started_at" : "2019-09-02T07:56:25.707000Z"
}
Mon Sep 02 10:42:09 GMT+02:00 2019 ReportSessionItemTask Response code: 200 OK
Mon Sep 02 10:42:09 GMT+02:00 2019 ReportSessionItemTask Response body: {
  "id" : 126587412,
  "object" : "assignment",
  "url" : "https://api.wanikani.com/v2/assignments/126587412",
  "data_updated_at" : "2019-09-02T08:42:08.845062Z",
  "data" : {
    "created_at" : "2019-02-08T15:03:32.874341Z",
    "subject_id" : 2856,
    "subject_type" : "vocabulary",
    "srs_stage" : 1,
    "srs_stage_name" : "Apprentice I",
    "unlocked_at" : "2019-09-02T06:51:52.378933Z",
    "started_at" : "2019-09-02T07:56:25.707000Z",
    "passed_at" : null,
    "burned_at" : null,
    "available_at" : "2019-09-02T12:00:00.000000Z",
    "resurrected_at" : null,
    "passed" : false,
    "resurrected" : false,
    "hidden" : false
  }
}

Based on the started_at timestamp, I was expecting available_at to be set to 11:00 instead of 12:00. And if I set started_at to null, that expected available_at does indeed show up.

Similarly, when I create a review and I supply a created_at timestamp some time in the past, then the review is correctly created with the created_at timestamo I supply, but the next available_at timestamp is not set as expected. (I won’t spam lengthy logs here, but I can supply some if needed.)

In both situations, some testing seems to indicate that the available_at is always calculated based on the current time, not on the started_at or created_at time.

Can someone confirm if this is intended behaviour? If so, that makes it a lot harder to properly support offline mode.

2 Likes

Just wanted to comment I saw your post about the issue. I’ll get back to you after I have looked into it.

Just want to give a heads up to anyone who uses the PUT /assignments/:id/start or POST /reviews endpoints.

Right now those two endpoints do not take into consideration of the user’s vacation status. Thus the endpoints are registering lesson starts and reviews even though the user is on vacation. It is not intended behavior. The intended behavior is to not allow registration of lessons and reviews while the user has an active vacation.

This has caused issue for these users when they get off of vacation. Basically assignments where lessons or reviews are registered during vacation time have their available_at fast forwarded to a time that is way outside SRS timings.

We are going to patch the endpoints up to respect vacation mode. The appropriate HTTP code and error object will return instead if an attempt is made to register on those endpoints when the API key owner is on vacation.

I recommend any users/scripts/applications who make use of the endpoints to check against the object returned in GET /user, specifically current_vacation_started_at before performing the actions…

We’ll have the API documentation updated once the change is live. We’ll also notify everyone here and on the API mailing list once the patch is active.

2 Likes

After tracing the code I can confirm with what you are experiencing.

Going to run it by the other devs first. Then will issue a fix.

2 Likes

The patch is waiting for a review. It’ll be a while before it is reviewed and pushed out live since we are running close to a deadline for our current project.

3 Likes

This patch is now live. All affected accounts have been adjusted to their correct SRS timings.

5 Likes

In a couple weeks we’ll release a very small update to GET /user/ and PUT /user/.

Under user.preferences we are adding default_voice_actor_id. This is the voice actor that is used as the default voice for autoplay during lessons and reviews. The ids can be found in vocabulary.pronunciation_audios.metadata.voice_actor_id. At the moment we have Kyoko which belongs to voice_actor_id 1 and Kenichi which belongs to voice_actor_id 2.

There is a pull request on the documentation site which documents the new attribute.

Will update here once again when the addition is live.

4 Likes

Hey :slight_smile: Any news on this? Apparently other people have also expressed their desire for something similar.

Any progress?

2 Likes

Yes, demote button please! Even if just through the API to start, it would be great.

2 Likes

This is now live.

4 Likes

Just a heads up on an upcoming change. We’ll have it out in one week (October 2). We are open to extending the timeline if someone who uses this attribute lets us know they need more time to adjust.

For assignment objects we are dropping the resurrected attribute, which has a boolean associated to it. The field is redundant while resurrected_at exists. The same information can be inferred by checking the presence of the resurrected_at value.

Here is the pull request in our docs highlighting the change.

2 Likes

With the risk of sounding like a broken record :smiley: :grin:

Any news at all regarding this? :slight_smile:

It seems like there would be some demand for this (Is it possible to disable burning items? - #4 by Pep95)

I’m just going to say again that I think a “demote” feature is the way to go. WaniKani should let you demote any item to a lower SRS level instead of just from Burned to Apprentice 1. This could even let you demote items to the Lesson state, and of course someone could build a script to mass demote Burned items to Enlightened state.

Maybe now that they’re (basically) done with the audio overhaul this’ll be their next project. :crossed_fingers:

7 Likes

Fingers crossed :crossed_fingers:

4 Likes

I would add a field to track the highest SRS level you’ve achieved, and then you could promote/demote anywhere up to that level.

6 Likes