API V2 Beta Documentation


#464

Added next_reviews_at to /summary. Will be live in a couple minutes. The value is null when the User has no reviews scheduled.


#465

Meaning either the user has never done any lessons or all active items have been burned?


#466

Yep, exactly!


#467

And what if vacation mode is enabled? Will the next review date get pushed forward each hour?


#468

Good question. In that scenario it should be null. Will do a hotfix for this now.


#469

The summary endpoint has been updated in my docs.


#470

Also, under the reviews and lessons fields, all the objects in the collection will return an empty array for subject_ids if the user is on vacation.


#471

Hotfix is live now.


#472

@viet @oldbonsai,

I found a few kanji that have amalgamation_subject_ids that don’t point to a valid subject_id:

kanji "川" amalgamation id 6390 doesn't exist
kanji "広" amalgamation id 4378 doesn't exist
kanji "図" amalgamation id 7633 doesn't exist
kanji "相" amalgamation id 7633 doesn't exist
kanji "面" amalgamation id 3877 doesn't exist
kanji "堀" amalgamation id 6390 doesn't exist

I checked if they were hidden items, and it doesn’t look like it.


#473

Thanks for the info.

I think I figured out the issue. Looks like those amalgamations are not visible to the user (role restricted). I’ll fix the scoping and will let you know when those kanji records get updated.


#474

The fix is now live.


#475

Hi @viet, do I have it right that there is no way to uniquely identify a user via the API?

When I fetch a user, I get their WK community username and their API key, but users can change their username and regenerate their API key. I want to allow people to change the API key in KameSame.com but I’m worried about the off-chance that they change the key to point to a totally different WK account, which could put their data in an indeterminate state (e.g. they have hundreds or thousands of different assignments than the other account did, I’ll have to figure out what to do).

Any chance we can get an ID or UUID for each user so we can be sure that a key reset isn’t changing their account identity?


#476

The account creation timestamp in /user should be as unique as you’d need. If they change API key, and the creation date doesn’t match, you know they entered a different account. (A uuid would be the normal solution, though, of course)


#477

That is a fair use-case.

I’ll write a quick spec for this, but can only promise a response to this early next month. Just want to run it by the other (developer) half first.


#478

hah, nice lifehack


#479

@viet Is the link to the audio included anywhere in the API?


#480

Not yet. They’re wanting to get the Terms Of Use done first.

But it’s easy to generate the url:
https://cdn.wanikani.com/subjects/audio/’+item.id+’-’+encodeURIComponent(item.data.characters)+’.mp3


#481

Is there a way to see when a review was last failed?


#482

Nothing very straight forward. You’d have to grab the /reviews endpoint and sort through the reviews.


#483

Ok, I think I see it. Correct me if I’m wrong, the review objects are snapshots, not the state of a single card. I assumed the values were overridden.