About

What is this?

This website provides a RESTful API interface to highly detailed objects built from thousands of lines of data related to Pokémon. We specifically cover the video game franchise. Using this website, you can consume information on Pokémon, their moves, abilities, types, egg groups and much, much more.

What is an API?

An API (Application Programming Interface) is a contract that allow developers to interact with an application through a set of interfaces. In this case, the application is a database of thousands of Pokémon-related objects, and the interfaces are URL links.

A RESTful API is an API that conforms to a set of loose conventions based on HTTP verbs, errors, and hyperlinks.

Aren't there 101 other Pokémon websites already?

Yes and that's exactly the problem!

101 instances of the same website means 101 instances of the same data.

We aim to provide a single source of data that any number of other websites can consume and use.

Often, and especially when new Pokémon games or updates are released, those 101+ websites take weeks to update as people have to enter the same information in all those different places.

This solves that problem. If all those sites consumed their data from here, they would have the exact same information that is updated at exactly the same time, with no errors between each website. The overall benefit is a better collaboration and consistency across all the different Pokémon websites and applications. It's good for all!

How much information is stored here?

A lot.

We currently have tens of thousands of individual items in our database, including:

  • Moves
  • Abilities
  • Pokémon (including various forms)
  • Types
  • Egg Groups
  • Game Versions
  • Items
  • Pokédexes
  • Pokémon Evolution Chains

And that's just scratching the surface! To see all the different types of data we have, check out the docs.

The API is missing stuff!

We know! Feel free to contribute to open issues on GitHub.

Have ideas for new features? We're on Slack! Sign up right here then visit our slack team.

So who built this?

Pokémon V1 was created by Paul Hallett as a weekend project but it quickly became more than a weekend's worth of work. In December of 2014 Paul deprecated V1 in favor of working on V2.

This is where Zane Adickes jumped in. Zane thought the original project was a fantastic idea and wanted to help it grow. With direction from Paul, Zane created the V2 API using an exact mirror of Veekun's data related to the main series of games.

In 2018, Paul decided to hand over the project to the community. A group of contributors came together and converted the API to serve static JSON files to improve performance and cut down on hosting costs. This website was also re-built at the same time.

We have a GitHub organisation of contributors that you are welcome to join!

Where did you get all of this data?

We gathered the information on this site from various resources:

  • Veekun has a fantastic Pokedex which is also an open source project containing a ton of csv data. We used this to flesh out the database that powers Pokeapi.
  • Bulbapedia has a tonne of extra information that proved useful when designing models and documenting resources.

We'd also like to thank:

  • Laven Pillay, who scraped together most of the sprites used on the site.
  • Alessandro Pezze, who worked tirelessly to add the Sun/Moon updates.

What's the technology stack?

Up until autumn 2018, the API and website were built together in a single Python project using the Django framework and paired with a PostgresQL database to store the data. Django REST Framework was used to expose the data through a RESTful API.

In autumn 2018, a group of contributors came together and converted the API to serve static JSON files in a fully backwards compatible manner. This allowed PokéAPI to move its hosting to a cheap static server (Netlify!), which increased performance and stability by a huge margin. At the same time, support for v1 of the API was dropped and this website was converted to a static site using Gatsby (a static site generator for React) and split off into a separate project.

The move to static hosting was solved by introducing a build step before deployment. This build step saves each possible endpoint as a JSON file using ditto, and it is these JSON files that are served from Netlify's CDN.