API V2 Beta Documentation


Kumirei is correct.

Radicals are primarily represented by an image due to not all of our radicals have unicode representation. If there is a unicode version, then we include it as a supplement.

In other words all radicals have images (and SVG). Some radicals have unicode.


And now if I could understand why resizing the SVGs results in some of them having blank squares rendering over parts, I’ll be happy.

I’m resizing the SVGs using CSS, so it’s probably something I’ve done there.


It looks like maybe your setup is trying to render the clipping masks with a white fill. They should only be clipping other rendered vectors, and shouldn’t actually be rendered themselves. Are you using the SVGs with CSS, or the ones without? What browser (or other tools) are you rendering with?

I’d recommend opening one of the clipped SVGs in the Elements panel, find the clipping mask(s), which should be inside a <defs> tag, and see what CSS rules are being applied to them.

Edit: What CSS are you using to resize them? You should be able to just set the width and height on the <svg> element.


@rosshendry: what @rfindley said. There should be two SVGs delivered with each radical: with and without inline styles, as indicated in the metadata object in the API response. Try the ones with the inline styles and see if that makes a difference.


I should be using the ones with stylesheets, but I’ve seen the effects of “should” on my code before! I’ll hopefully have some time to pick this up again next week, I could really do with a leech window on my desktop at all times.


For what it’s worth, I use the ones without inline styles, then just add the following CSS on the page:

svg.radical {
    fill: none;
    stroke: #000;
    stroke-width: 68;
    stroke-linecap: square;
    stroke-miterlimit: 2;

I’ve tested that in Chrome and Firefox, and both work.
If you’re rendering at small size, you may want to reduce the stroke-width.

And to set the size:

svg.radical {
    height: 40px;
    width: 40px;


Not sure if this is intentional, but the API is available over normal HTTP as well as HTTPS. That could be a security issue when sending authorization credentials.

EDIT: I’ve also just noticed, the kanji and vocab data both have subject_component_ids listed as a property, but the actual API returns component_subject_ids


That did it! No stylesheets, and the styles you were using. If I get the time, it’d be nice to compare the stylesheet you’ve provided with the one in the SVG.


Hmmm, how’re you getting to the endpoints over http? My usual set of testing tools is consistently reporting 301 responses when I hit anything at http. I can see how a 403 or something similar might be a better response, though. :thinking:


Ah, so it is. I was using insomnia and the swagger editor to test some interactive documentation I was working on, and they were both hiding the 301 from me (in insomnia, it shows up in the timeline)

pinned #434


I’m working on interactive docs for the new API (OpenAPI 3.0.1 standard), and I have a couple questions:

  1. For the srs_stages endpoint, are you using 64 or 32 bit integerss to store the intervals? EDIT: 32-bit is fine regardless; I strongly doubt there will ever be a decades-long SRS stage
  2. Likewise, for resource IDs, are they 32 or 64-bit? I’ve never seen anything over 100 million, but I want to be safe.


32-bit. I don’t foresee exceeding this…

All are currently 32-bit. The “large”, by far, resource ids can be found on /reviews (200,000,000+). At some point we may have to entertain the idea of changing it to 64-bit.


I have my first version of the v2 API Docs:

You can copy one of the above links into the top text box at petstore.swagger.io and get the same result.

My github repository (https://github.com/bennettBuckley/WaniKaniAPI) has UI components that will give you the same experience, but without the green bar at the top.

@rfindley, whould you be willing to host the UI components on the WKStats site?


I could do that, though I’m curious why not just use raw.githubusercontent.com?


It returns any text-based data as text/plain, which doesn’t play nice with the html.

see here: https://raw.githubusercontent.com/bennettBuckley/WaniKaniAPI/master/ui/index.html

I’m pretty new to github, so maybe there’s a way to do it I don’t know about.


Ahh, makes sense, and I remember reading about that now that you mention it. You could also look at github.io, though, which hosts a site directly from a repo. But I think it’s limited to one site without a subscription, if I recall correctly.

But I don’t mind hosting the images.


Thanks for letting me know! This is so much easier than tracking down some free hosting.
https://bennettbuckley.github.io/ for anyone interested

The copy is lifted straight from the first post, minus the tables (CommonMark doesn’t support them yet). Let me know if there’s anything in the docs that you’d like to see updated.


This update will be live tomorrow (about 16 hrs). Just wanted to write this up to get it out of the way.

For /subject resources we include component_subject_ids, which point to subjects which compose the primary subject in question. Vocabulary has kanji components. Kanji has radical components. Radicals do not have components.

The update will add amalgamation_subject_ids. You can kind of think of it like the reverse of component_subject_ids. The attribute lists subjects which has the primary subject as a component.

Radicals are an amalgamation element of many Kanji (if you look at a subject page, such as this one), its analogous to the “Found in Kanji” list.

Kanji are an amalgamation element of many Vocabulary (if you look at a subject page, such as this one), its analogous to the “Found in Vocabulary” list.

Vocabulary are not an amalgamation element of anything.


My docs have been updated with the new fields.

UPDATE: I’ve also manually written an example for the Subject Resource. Since there were three possible types, the docs weren’t auto-generating an example.