Notable API performance increase

Hey :wave:t2:

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.


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:<apikey>/vocabulary

It took 15 to 18 seconds. Granted, I’m level 60, so that’s the worst-case scenario.

1 Like

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

User synonyms splitting & "undefined"

Everything should be good now, per new comments on the thread.

1 Like

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.

1 Like

Hotfix is now live. Let me know if this fixes the issue.

Yep, we are good! :ok_hand: 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:

  • 40 RPM
  • 240 RPH

You may or may not need to adjust your staggered requests. Subject to change.

@Tadgh11 @rfindley

(Just so you’re aware.)