I wanted to ask a specific directed question about WaniKani’s public API: why is there no action to unburn/resurrect an item? I know this subject has come up tangentially in threads many times before before, but even after reading many of them, I couldn’t find a good answer.
Context: I started burning items for the first time a month or so ago. Most of the time, this was fine, but there’s been more than a few so far where I cringed to see the “Burn” result appear when I got the right answer because I knew that I got it just barely — ask me again in two days and it would be a 50/50.
WaniKani’s API is incredibly fully featured. As we’ve seen with apps like Tsurukame, it’s so fully featured that it’s actually possible to reimplement the WaniKani platform in just the API. Speaking as someone in the API tech space, I can tell you that this is incredibly rare — in most cases even if a product has a good API, it’s never a complete API — there’s always enough missing functionality to ensure that no 3rd party could ever realistically vie with the 1st. WaniKani is notably not like that, which is great.
I’m not trying to do anything extreme. I set about solving my burn dilemma by writing a script that would run in cron to unburn one item at random per week — not enough to risk overwhelming my review queue, but enough to add some dynamicism to it by reminding me that those items exist. I got 90% of the way through implementing it assuming that of course you could unburn an item through the API before getting to the very last step and realizing you can’t.
I know that:
-
Unburning can be risky business because it if done too aggressively, you can overwhelm your review schedule.
We would of course have to be careful with an unburn endpoint, but it wouldn’t be without precedent because there are pre-existing endpoints in the API that can mess up an account’s state badly if abused.
-
It’s technically possible to resurrect an item by simulating a browser request to the web app’s
/assignments/:id/resurrectendpoint (include a CSRF token, etc.). I checked experimentally if this might exist as an undocumented API endpoint as well, but alas, it doesn’t.
I’m wondering specifically: given how relatively fully featured the API is, and the fact that the functionality already exists in the web app’s internal API, why omit it from the public one? It seems like a shame given you can do practically anything else. Ideally, it would be amazing to hear from a WK developer or someone in the know as opposed to outsider speculation.

I suggest you use that.