Upcoming API v2 Key Changes

WaniKani API And Third-Party Apps
1

TL;DR:

  • All the existing API keys are not getting changed and will keep working, so no one panic.
  • We added some writable endpoints to API v2.
  • We’re adding the ability to have multiple API keys with different permissions.
  • Scrapers out there need to update their code.

We recently added PUT and POST endpoints for updating user preferences, finishing lessons, answering reviews, and creating study materials (notes and synonyms). Documentation on all of them are in the works or already live — take a look at the documentation, the documentation repo, or its open PRs.

These additions call for some kind of permissions, since not every tool should have access to write to your account. Permissions are in place right now; the defaults allow all reads and deny write access, working just like before. “But, that means I can’t use those endpoints!”, you say?

Well, we’re allowing everyone to have multiple API keys (a.k.a. personal access tokens) and set different permissions on each one, including write permissions to those fun new endpoints. The tokens can be named and expired, making it easier to say who has access and also take that access away.

To manage all that, we’re moving tokens into their own section of the user settings. We’re putting the finishing touches on the UI, but the changes will launch March 18 during the morning Pacific time. The new interface will be at WaniKani — Log in. The API v1 key lives in a similar spot on the page with a similar interface as before (a read-only input field). The API v2 keys, though, work way differently, appearing in a list, having names, and generally being fancier.

That means all you fine people that scrape API keys off the current interface are looking at a breaking change. We discourage scraping for the API keys since it bypasses some user consent and is subject to breaking changes without announcement, but we know it’s done. If you have to scrape those keys, this is your chance to fix up your process.

PS. We’re working on making WaniKani an OAuth provider. We’ll post more information as we get closer to launching this, but we’re hoping that it solves the scraping problem for those applications out there that sacrifice enough turtles to the Crabigator would benefit from OAuth.

16 Likes
2

API endpoint to let you demote items next? :slight_smile:

4 Likes
3

In case it helps…

Open Framework currently scrapes the APIv2 key because:

  • It eliminates a step that some users find confusing (“What’s an API key, where do I find it, and where do I put it?”).
    • Potential solution: I could document a manual process in a thread, but documentation breaks just like scraping does. OAuth will solve this eventually.
  • For some reason, people regenerate their key a lot more than I expected. And when they do, scripts stop working, and users often don’t connect the dots as to why things are broken.
    • Potential solution: I could do better detection and give better notification to the user as to why things aren’t working.
  • When a different user logs in on the same PC, I want scripts to automatically adapt (by scraping the user’s key) so they don’t have to re-enter their key every time.
    • Potential solution: I could store multiple keys, so each user will have to enter their key only once.
7 Likes
4

Neat, now we don’t even have to visit WK to do our lessons and reviews

6 Likes
5

“And thus, Kumirei was never seen or heard from again”

7 Likes
6

AAAAAAAAAAAAAAAA…

…AAAaaa ah. Ok.

Awesome, though!

7

Now I just need to figure out how users could enter review responses on a watch…

Oh, wait, I haven’t announced that project yet, have I? Oops! ^^

2 Likes
8

I would be impressed if you don’t make it anki mode

9

don’t say that, you are gonna make our favorite little guy sad.

crabigaor
crabigaor1200×1200 31.2 KB

10

Spitballing here, this doesn’t address every case you mention but the edge case with two users on one machine should really, really, be solved with the users having different browser profiles or something to that effect. It’s hard to think they won’t be stepping on each others toes with every other service they both use. imo

What if there was a mechanism to generate a link that spec’d out the key the user would need to generate for a given plugin. So a plug-in author would be able to detect the absence of an API key, then respond by taking the user to the keys UX where the new key could be cranked out. You’d also relieve the user of having to name or track the keys themselves on the WK side. I don’t think users are otherwise going to make descriptive names for the keys, usually.

11

I would love to have access to an OAuth endpoint, an update to my iOS app just got rejected because Apple guidelines don’t allow you to use API keys:

image
image1848×556 62.1 KB

image
image1130×468 25.4 KB

12

Oooph, super annoying!

Sadly, we’re still ironing out the wrinkles in the OAuth implementation. We have to work out a (business) process for figuring out how people register their apps with us. We’ll announce something on the forums and on the API mailing list as soon as there’s something to announce.

2 Likes
13

What about on a FitBit?

14

Thanks, I think to get around this I’ll have to write something that scrapes the API key from a mobile webview. I’m assuming from this thread that for now this is “ok” in the not-really-but-its-unfortunate sense of the word. If you need a guinea pig for OAuth I’d love to be of any help.

As a side note, I hope that things don’t become difficult for anyone wanting to build an iOS integration. This is 100% on Apple. The guideline they rejected me under is “In-App Purchase”, and they’ve been pressuring developers into adding in-app purchases. If this is the road Apple is pursuing there won’t be any helpful apps available for iOS users :frowning:

15

The good news is once the OAuth is implemeted, the API link is good as done. It’ll be just like Facebook integration as far as apple is concerned.

1 Like
16

I doubt that it’s any easier to type review responses on a FitBit than on a Gear…

Probably wouldn’t be a bad platform for a basic status tracker app, though. Don’t know anything about their development process; I’d have to investigate. I don’t have the excuse that I don’t have a physical device to test on, I guess, because my wife does have a FitBit of some sort.

1 Like
17

The challenge here is that WaniKani is a paid service, whereas Facebook is free. An acquaintance of mine was recently forced to implement in-app payments by Apple. Apple doesn’t like the path of “installing app” → “go to website to pay for a subscription” and I thik that’s at the heart of preventing me from integrating via an API key

18

There are other WaniKani apps that use the API though. What is different about yours?

19

I think the main difference is that those were published way earlier, before Apple got stricter about this.

20

I think if WK ever implements an authorization form for OAuth2, the problem is gone; the issue is inputting an API key, not using an external service. Look at all the apps that use facebook, google, or microsoft accounts. iOS review even has a section for supplying login credentials to the apple reviewers.