What a PokéAPI Pokémon Response Looks Like

A PokéAPI Pokémon response is a JSON object returned from https://pokeapi.co/api/v2/pokemon/{name-or-id}. It contains the Pokémon's core attributes (height, base_experience), nested arrays for abilities, forms, game_indices, and held_items, and every related entity is represented as a { "name": ..., "url": ... } pair pointing to another API resource. The example on the PokéAPI homepage for Ditto (https://pokeapi.co/api/v2/pokemon/ditto) shows this structure directly.

The top-level shape

Requesting a Pokémon returns one object whose keys describe different facets of that Pokémon. In the Ditto example, the visible top-level fields include:

The response is not a flat record. It is a graph of references: the Pokémon object tells you what exists, and the URLs tell you where to fetch the details.

How nested references work

Every related resource follows the same pattern: a name plus a url. For Ditto's abilities:

"abilities": [
  {
    "ability": { "name": "imposter", "url": "https://pokeapi.co/api/v2/ability/150/" },
    "is_hidden": true,
    "slot": 3
  },
  {
    "ability": { "name": "limber", "url": "https://pokeapi.co/api/v2/ability/7/" },
    "is_hidden": false,
    "slot": 1
  }
]

The Pokémon endpoint gives you the ability's name and a link. To learn what "limber" actually does, you follow https://pokeapi.co/api/v2/ability/7/. The same applies to forms (.../pokemon-form/132/) and to each version inside game_indices and held_items.

This design keeps the Pokémon response compact while letting you drill into any linked resource on demand.

Reading version-specific data

game_indices and held_items are where the response becomes version-aware.

• game_indices lists the Pokémon's in-game index number for each version. Ditto shows game_index: 132 for most versions but game_index: 76 for red, with each version carrying its own name and url.
• held_items nests a second level: each item has name/url, and inside it a version_details array listing rarity and the version where that hold rate applies. Ditto's metal-powder entry shows rarity: 5 across multiple versions such as moon, x, black-2, and heartgold.

So if your task is "show which items a Pokémon can hold in a specific game," you filter held_items[].version_details[] by the version name rather than reading a single global value.

A practical way to explore it

1. Open the resource URL https://pokeapi.co/api/v2/ and submit a path such as pokemon/ditto, or go directly to https://pokeapi.co/api/v2/pokemon/ditto.
2. Inspect the top-level keys to see which facets exist for that Pokémon.
3. Pick a nested url (for example an ability or version) and request it to resolve the reference.
4. For lists, use query parameters like pokemon?limit=100000&offset=0 to page through the collection.

The homepage also offers hint paths such as pokemon-species/aegislash, type/3, and ability/battle-armor, which are useful for seeing how other resource types compare to the Pokémon shape.

Common points to watch

• Names vs. IDs: endpoints accept either a name (ditto) or a numeric ID, and the returned url fields always use IDs.
• References are not inlined: a url is a pointer, not the data. You must make a second request to get ability text, item details, or version metadata.
• Version nesting: held_items and game_indices are per-version, so aggregate values require iterating their arrays rather than reading one field.
• Field coverage varies: the fields shown for Ditto are the structure to expect, but not every Pokémon will populate every array with the same depth.