This is my first time posting on the forum, so I apologize if this is somehow in the wrong place. I wanted to share some insights from an email exchange with WaniKani, which I think could be helpful for us here.
So, here’s the good news: WaniKani seems to be gearing up for some updates this winter. They mentioned it in passing: “Just letting you know that we’ve read your email… the timing of your email is just in the middle of some other decisions that we need to make first before the winter holidays.”
On a slightly cautious note, they also hinted at potential changes that could affect their API: “We’re still discussing this (not just your request, but a few other related API topics)… please keep in mind the risk of spending time on something that may need to be changed later based on the WaniKani team’s decisions.”
Since the WaniKani team hasn’t made any official announcement regarding these changes, I figured I’d make this post warning other developers of these changes before they go live.
We’ve had a discussion about this but the API should only be used for personal use. If you’re creating something to improve the way you’re studying Japanese, that’s great, but the API shouldn’t be used to build something for other people.
I’m super confused by this statement from WaniKani. This is completely contrary to how virtually everyone uses the API.
Erm, is this a joke? People have been making requests to WaniKani for years and many of them were not accepted, however a ton of not necessarily high priority content changes (see: する compound type renames) were made.
Same. That would significantly cut into the usability of WaniKani for a ton of people.
Not just how people do use it, but it feels like that’s completely against why one would bother having an API in the first place. What is the purpose of providing a programming interface if not to allow people to create things that can be shared with others using that interface?
I’m definitely more inclined to believe that whoever handles replying to emails like this is not a developer, more on the PR side of things, and is erring on the side of legal precautions to say they don’t support third party development.
That’s fair and it’s understandable they are not able to support third-party apps, but even if the email chain is not an “official announcement”, it is a statement from a company employee and thus is binding.
It’s pretty tacky to share private communications to stir up drama based on nothing but speculation. You already have people worried that scripts are going away based on… what exactly? Nothing in the emails suggests that.
I tend to doubt there’s any specific looming change; they’re just cautioning that the app could break in the course of normal API updates, and that it’s on you to support.
You’ll often see posts here asking why WK is broken, neglecting to mention they’re using a depricated third-party app or haven’t updated their scripts in months. This is extra work for WK’s team. Is any third-party app officially approved by WK?
I’d be inclined to believe (and would hope) that that was just a badly worded way of saying that they don’t want the API to be used by someone to pre-fetch / store WaniKani data (such as kanji info, mnemonics, etc.) and then distribute / provide it to users, rather than what I assume is your interpretation of it meaning creating something that makes use of API calls while the user is using it
I was never asking for official approval by WaniKani. If you look at the initial inquiry I made in the email, I was asking a question about the API. The email is at the top of the API documentation, welcoming questions regarding the API.
I think this is an unfair comparison. The public API is completely different from scripts that rely on internal code or HTML structure. If a third party app is solely relying on the public API in accordance with the API documentation and guidelines, then it should never break. If it breaks it’s likely because WaniKani broke the API contract, whether intentionally or due to a bug, and that would be WaniKani’s fault, not the fault of the app developer. The whole point of a public API is that it has a defined contract that doesn’t change. On the other hand, many scripts break because they are relying on internal code which WaniKani has no obligation to keep as-is.
I just noticed something. This is from the WaniKani API documentation (reference):
Cache subjects as aggressively as possible. They aren’t very frequently updated, and you’ll probably need to access them frequently. They’re the object that ties together assignments, review statistics, and study materials.
Even if what you are saying is true, the idea that caching such info isn’t allowed when the documentation heavily advises you to do so is still contradictory.
I hope this was just a miscommunication on their end.
While hoping that there wouldn’t be breaking changes in the API, I am not very certain that WaniKani would be able to maintain the API always, or at least communicate well enough. (Thinking about an endpoint that never came back.)
Mobile apps are at WaniKani’s mercy, especially when WaniKani is already making the website more mobile-friendly (but not necessarily good enough).
I assume this means caching on the user’s end rather than the script/website creator’s end though. I’m guessing that maybe what they don’t want is someone creating/running a website that makes use of and stores WaniKani data?
If this were the position that the WaniKani team had, I’d understand. Still, there are statistics websites (like wkstats), which the WaniKani documentation acknowledges in their documentation, that also cache subjects and serve them to users (reference):
Let’s say you’re building a statistics site. You need to know about all the subjects plus get all of a user’s assignments, review statistics, reviews, resets, and level progressions to figure out how they’ve done in the past and do some guesswork on how they might do in the future.
The problem would then be a lack of communication from WaniKani as to how they want users to use their API.
I am not sure about that. I think there were changes in the staff (we don’t see @Viet anymore) and the new staff doesn’t have the same expectations about scripts that the old ones. I think @Viet saw scripts as an added value for the site. The new staff sees them as a source of problems.
@StayBlue You have a critical misunderstanding about caching. wkstats caches subjects clientside - users still need an API token to access them and wkstats’s server or app itself never serves these subjects to users. This is entirely within the recommendations of the API, the terms of service, and the consistent stance the WK team has held on API usage.
