Repository navigation
Unonw-A is missing a bunch of sprites #1687
Description
Describe the Bug
Of all the unonw forms, on unown-a (pokemon-form/201) is missing sprite data. It only has two backsprites, all other fields are null.
The interesting part here is, that all other forms (pokemon-form/10001 and above) do have full sprite data available. unown-a is the default for, so one could argue that is no problem, as the pokemon resource should have all sprites of that one as well. However, the unown pokemon resource (pokemon/201) is inconsistent in that manner. It does have sprite data, and most of the point to unown-a images, but the artworks for example are of unown-f, not a, meaning there is currently no way to get the A-Artwork via the API, even though all the others are available.
Note: I did not look into it yet, but that might have to do with #1681 . @FallenDeity may you can confirm whether that is a preexisting issue or a problem introduced by your change?
Steps to Reproduce
GET https://pokeapi.co/api/v2/pokemon/201-> Artwork is Unown FGET https://pokeapi.co/api/v2/pokemon-form/201-> Artwork is missingGET https://pokeapi.co/api/v2/pokemon-form/10001-> Artwork is Unown B
Resolving the Bug
Anyone is open to making a PR for this issue.
Activity
FallenDeity commentedon Sep 26, 2026
which set of sprites are u looking at official-artwork?
I added 201 form sprites here but not 201 itself so thats was incorrect from before https://github.com/PokeAPI/sprites/pull/282/changes
a pr updating this is needed https://github.com/PokeAPI/sprites/blob/master/sprites/pokemon/other/official-artwork/201.png
regarding the missing in form that is a bug yeah i am not falling back properly the defautl form has
-aidentifier but 201 is the default there is no separated 201-a so that fallback needs to be handledSkycoder42 commentedon Sep 26, 2026
I agree, updating the sprite of 201 would at least make it consistent. But is the fact that unown-a (pokemon/201) has no sprite data attached to it? I guess it is fine if the intended logic is "default form sprites are identical to the pokemon", but that is inconsistent to pokemon that have unnamed default forms. Case in point.
https://pokeapi.co/api/v2/pokemon-form/200: Is the default form of misdreavus, same number as the pokemon, no form_name. It has all it's sprite data filled with the identical URLs as the ones fromhttps://pokeapi.co/api/v2/pokemon/200https://pokeapi.co/api/v2/pokemon-form/201: Is the default form of unown, same number as the pokemon, has a form_name, unown-a. Most of its sprite data is missing, only some URLs are present, all ending in.../201-a.png.This looks unintentional to me. Could that be a bug in the new logic?
FallenDeity commentedon Sep 26, 2026
i did mention the reason in my earlier comment it needs a fix, also most of them are not missing versions is mostly fine its the official artwork and showdown etc ill fix that in a pr soon or feel free to make a pr too :) meanwhile u can fallback to pokemon endpoint
the logic for sprite lookup basically needs a small change where we check if its
is_defaultwe use the name directly for lookup else we add form suffixSkycoder42 commentedon Sep 26, 2026
Okay, thank you very much for your quick reply!
Fall back to the pokemon id for default form sprites
Fix Omega Ruby/Alpha Sapphire sprite key in generation-vi sprites (#1689