Hey 
We pushed some changes out this morning which drastically increased the perfomance of the current (v1) of the API. Some end points are seeing a couple magnitudes of reduced response times, notably the vocabulary end point.
Before it would time out when doing a non filtered request for users who have progressed significantly. To get around this developers did multiple filtered requests. This is no longer required since the endpoint should no longer tiemout.
Give it a try.
Great!!
Iāll do some testing on my scripts, and will push the changes if everything checks out. iāll post results here.
I did some tests from the stats site, which does 5 levels at a time. Doing multiple filtered requests is much faster than before!!
I did an unfiltered request for vocabulary:
https://www.wanikani.com/api/user/<apikey>/vocabulary
It took 15 to 18 seconds. Granted, Iām level 60, so thatās the worst-case scenario.
Can this be connected to the user synonyms being āexplodedā to letters?
How long did it take before?
Which item are you seeing this?
I donāt rememberā¦ itās been a few years since I tried it. But it was fairly common for it to fail the first time due to browser timeout. Retrying usually worked fairly quickly, Iām guessing because the information was pulled into server cache.
Iām somewhat hesitant about switching to unfiltered requests for vocab since it still takes a while, especially since splitting it up works so much faster. But maybe I can increase it from 5 levels per request to something higher. Iāll experiment later.
I think Iām experiencing the same bug as @hallgat89
Everything should be good now, per new comments on the thread.
Ah, this is why. Before it took about 4~ seconds to get my currently unlocked kanji/vocab (329/920), now both requests take only a second. Neat.
Wow, just loaded rfindleys stat site. Near instantaneous!
Good work <3
Hey @viet uhā¦think Iāve run into a small change in the API. Occasionally, A userās burned field in their user_specific in the vocabulary_list, which was previously a boolean, now contains null. Please let me know if Iām wrong about this, but Kaniwani is now puking up a fair few errors on userās trying to unlock lower levels when this is the case. Seems pretty sporadic though, I havenāt encountered it myself yet.
"requested_information": [
{
"id": 1176,
"level": 12,
"character": "ęē« ",
"kana": "ć¶ćććć",
"meaning": "article, sentence, composition",
"percentage_correct": 92,
"user_specific": {
"srs": "burned",
"srs_numeric": 9,
"unlocked_date": 1440221730,
"available_date": null,
"burned": null, <---------------------THIS ONE
"burned_date": 1484280316,
"meaning_correct": 17,
"meaning_incorrect": 3,
"meaning_max_streak": 6,
"meaning_current_streak": 6,
"reading_correct": 17,
"reading_incorrect": 0,
"reading_max_streak": 17,
"reading_current_streak": 17,
"meaning_note": null,
"reading_note": null,
"user_synonyms": null
}
},
Not sure if this is intended or not. Little odd since they have a burned date, but null value in burned field. @rfindley have you run into this?
Hmmm Iāll look into this now. Our specs have type checking for the API responses, so this is surprisingā¦ Will let you know in a minute.
I can provide you various API keys/ level calls if you need to replicate.
Iāve pinpointed the issue. Going to issue a hotfix.
Hotfix is now live. Let me know if this fixes the issue.
Yep, we are good! 
Thanks for your promptness.
Want to note an additional change here:
We have updated the throttle rate of the API. Before the setting was 100 RPH. We have now switched it to the following:
You may or may not need to adjust your staggered requests. Subject to change.