API V2 Beta Documentation

WaniKani API And Third-Party Apps
364

year that still means that all those software breaks

365

Right. The developers of those scripts will have to switch to the new API.

366

Or new people will develop new scripts. It’s not like the community is dead or anything.

1 Like
367

Yeah, I think for the scripts that are really desirable, we have enough coders here that they will be updated. In fact, that’s how I got started with userscripts: adapting Timeline from a Chrome browser extension after the original author left and support for the extension was dropped.

All of my scripts will be converted over the next few weeks now that the Open Framework (for APIv2) is released.

3 Likes
368

Hi, I’m new to this API.

It looks like it’s all readonly endpoints? Or is it possible to develop a native iOS app that can do reviews?

369

As it stands right now, it’s read-only. For the native iOS app, you’d need to follow the lead of the other mobile apps that are out there right now and use web views to include the lesson and review interfaces. There are some gotchas around authentication with that (mainly that it’s kind of painful either with an API key or trying to use their username and password).

(cuts himself off from talking about exciting upcoming changes — but not before the words “writable endpoint” and “OAuth” slip out in the mumbling)

8 Likes
370

Some changes which are now live:

  • All Subject.type radicals character_images now output a collection of assets: PNG visual representations in various sizes, CSS-stylized SVG and SVG without any CSS embedded stylization.
  • Subjects now have attribute hidden_at. When a subject is removed from the user facing component of the application the attribute will be timestamped.
  • Assignments, Review Statistics, and Study Materials now have attribute hidden. When the related subject is hidden, this attribute is set to true.
  • hidden filter is available to the collection endpoints of /subjects, /assignments, /review_statistics, and /study_materials.
  • The default scope of the endpoints /subjects, /assignments, /review_statistics, and /study_materials is to show both hidden and non-hidden subjects.
3 Likes
371

And here I was hoping that this was hinting at an upcoming feature to let users hide (aka suspend) reviews for individual items that may be bogging them down.

372

Awesome! I’ve been looking forward to this.

Just a note for everyone:
To make use of the un-styled radical SVGs (which allow you to centralize the CSS in one place), you can add the following CSS to your page:

svg.radical {
    fill:none;
    stroke:#000;
    stroke-linecap:square;
    stroke-miterlimit:2;
    stroke-width:68px;
}

@viet,
The SVGs with style don’t have class="radical". I didn’t know if that’s intentional. I don’t guess I have an opinion either way
 I just happened to notice it.

Also, looking at the character_images collection, since the array contents are in a different order in each item (based only on looking at subject_id=1 and subject_id=400 so far), I would be interested in having a more machine-friendly field for identifying the contents.

For example, on the SVGs, maybe something like:

    "has_style": true

And for the PNGs:

    "size": "32x32"

or

    "size": 32

??
Any thoughts from other scripters and app developers?

[edit: As long as the description isn’t likely to change, though, a simple match against the description would work fine]

1 Like
373

Sorry for not getting back sooner.

Darin and I chatted over this last week. I think we will drop the description attribute (it is a humanized description, which we are now thinking it isn’t appropriate) and add a metadata attribute with an object value. The metadata will contain details depending on the content_type. This should make it machine-friendly.

Will get back to you on that one.

374

I should expand on the main purpose of including these fields.

A while back a few developers brought up on how to identify subjects/assignments/review_statistics/study_materials which have been “deleted” from WaniKani. There wasn’t a good way to do this, other than pulling the entire collection of resources. This is not ideal.

The developer is now able to identify items which have been soft deleted from the system. When a subject is “hidden”, the update cascades to related assignments, review_statistics, and study materials, which toggles their “hidden” attribute. This also touches the updated_at. If the updated_after filter is leveraged, then it should be easy to identify if a subject has been removed from the system. Do note the resources can be toggled the other direction (hidden → unhidden); the fields will be reset back to null or false.

1 Like
375

PSA: We’re changing the URL for API v2 —you’ll find all your favorite endpoints at https://api.wanikani.com/v2!

The structure of the requests and responses stay the same, so update those base URLs and you’ll be good to go. We’re supporting traffic to the old endpoints for a couple weeks while everyone makes the transition, but we’ll be tearing down the existing URLs on April 18.

As usual, let us know if you’ve got any questions or concerns. :smiley:

1 Like
376

Just confirming that this particular notice has nothing to do with V1 URLs, correct?

377

Nothing has changed with V1. There are no plans of changing the base URL for V1 endpoints.

378

Open Framework is now switched over to the new APIv2 url.

3 Likes
379

I’m currently working on a project where I need to fetch all review/assignment data at once. Is there a good way to go about this in a timely manner without putting a big load on the server?
For my personal data I’ll probably fall within the 60 RPM limit, but I don’t know how that’ll look for higher level accounts. I might run into the limit there and then I’d have to make the user wait until I can request again.

380

As long as you’re caching your result and making use of the updated_after filter, full-data queries should be infrequent enough that it won’t matter to the server. You’d probably only have a problem if, for some reason, a bunch of users decided to do a full-data query at the same time. But with caching, most queries should end up being very minimal incremental updates.

In the Open Framework, I just check for a rate-limit error (429), and do a retry after a delay. WIth each successive retry, I increase the delay. When it finally succeeds, I reset the delay back to initial.

1 Like
381

Thanks for the quick reply! So I’ll just have to suck it up if I hit the limiter^^

I guess I could also calculate how many requests I’m going to need and then set the delay accordingly so I don’t run into the limiter. But depending on how long I’ll have to wait if I hit the limiter that might not even be faster.

382

You’re probably better off not trying to sculpt your reviews to avoid the rate-limit. What if they increase or decrease the limit in the future? Or worse yet, adjust the rate dynamically?

I’m definitely in favor of being considerate regarding server load. Under the old system, I spent a lot of time trying not to be an undue burden. But under the new API, with incremental query support, I think we don’t have to worry about it as much, and they’re better equipped to refine the server load on their end as needed.

But, of course, I don’t speak for Tofugu. I’m just a frequent API user :slight_smile:

1 Like
383

On a side-note
 I’m probably soon going to be responsible for their biggest live load-test yet. After I finish upgrading the Self-Study Quiz script to APIv2 this week, I’m going to do a quick upgrade of Ultimate Timeline. That’s going to shift thousands of users onto APIv2 in a very short period of time.

2 Likes