Potential Upcoming Changes to WaniKani API

To suggest that I have a “critical misunderstanding” about anything when none of this is effectively communicated to consumers of the API is misguided and distracts attention away from the point I was trying to make (regarding communication). I don’t know if what you are telling me is true because nowhere in the documentation, terms of service, or otherwise does it suggest that caching subjects on the server isn’t allowed. If what you are saying about caching subjects is true, I wouldn’t even have a problem with it. My application already requires that you tie an API key to your account when you register; otherwise, the application is unusable.

1 Like

That would align with the response I received from WaniKani in the email. While this is just speculation at this point, I hope for the sake of users, the API isn’t going anywhere.

2 Likes

I agree with this. WaniKani’s core intellectual property is their database of content. I’d think they’d be concerned about people scraping the entirety of their content and presenting it to users in a fashion that they don’t, or can’t control, despite the API having the technical ability to do so.

There’s a difference between individual caching at the client level, and service caching at a server level. You are proposing to do the latter, which if I were WaniKani, I would not be comfortable with. And in fact, if I knew there was a database out there with WaniKani’s entire dataset of content, and that content was being served to users of a third party system, and I were on WaniKani’s legal team, I’d very likely be sending cease and desist letters.

1 Like

I appreciate your perspective on the caching strategy. Here’s a snippet from WaniKani’s API documentation (reference):

Most of the data delivered by the API belongs to you: assignments, study materials, review statistics, and those bits about how you progress through WaniKani. The only data that isn’t yours is the content in subjects. All those mnemonics, hints, and relationships have been painstakingly crafted by the WaniKani staff to make learning kanji faster and better. That content is covered by pertinent copyright laws — which also means that fair use allows you to use it to learn on your own. Once you start building tools that can be used by other people, things change, though. First, you can’t use the content to build anything that’s for profit.

Initially, my plan was to cache subject data on the server. This was mainly to centralize logic processing and minimize API requests to WaniKani’s servers. Since my app is not designed for profit, I believed this approach was compliant with the guidelines.

However, after the discussion with WaniKani, I recognized potential issues with this approach. The nature of the changes they are planning to make to the API is still a mystery, so I have to be extra cautious. To address this, I’ve adjusted the architecture: the server now only stores subject IDs, while the client handles the bulk of the logic. This respects WaniKani’s content while maintaining efficient app functionality.

1 Like