API testing can feel a little abstract when you are starting out. You send a request, receive a screen full of JSON, and then wonder what you are supposed to look at.

Using familiar data makes the process much easier. That is why the Pokémon API in Fun API Playground is a good place to begin. You can find Pikachu, filter Pokémon by type, catch a new Pokémon, and even simulate a battle. Behind the fun theme, you are still working with real API concepts such as HTTP methods, status codes, authentication, and JSON responses.

In this guide, we will start with a simple GET request in Postman. Once that works, we will try filters, trigger an error on purpose, and finish by sending an authenticated POST request.

No signup or private API key is required.

Before We Start

You will need Postman and an internet connection. The desktop version of Postman is usually the most straightforward option, but the web version works too.

All the requests in this tutorial use the following base URL:

https://funapi.dev/api/pokemon/v1

A base URL is simply the common part at the beginning of an API’s endpoints. We will add paths such as /pokemon and /battles to it as we go.

You can keep the full Pokémon API documentation open in another tab if you want to explore beyond the examples here.

Start with a Simple GET Request

Open Postman, create a new HTTP request, and make sure the method is set to GET.

Paste this URL into the request field:

https://funapi.dev/api/pokemon/v1/pokemon?page=1

Click Send.

If everything is working, Postman should show a 200 OK status. The response body will look something like this:

{
  "page": 1,
  "pageSize": 4,
  "total": 8,
  "totalPages": 2,
  "data": [
    {
      "id": 1,
      "name": "Pikachu",
      "type": "electric",
      "level": 12,
      "hp": 60,
      "_v": 1
    },
    {
      "id": 2,
      "name": "Bulbasaur",
      "type": "grass",
      "level": 10,
      "hp": 65,
      "_v": 1
    }
  ]
}

There is quite a bit going on here, but you do not need to understand every field immediately.

The data array contains the Pokémon records. Each Pokémon has an ID, name, type, level, and HP value. The fields above the array describe the current page.

This is called a paginated response. Instead of returning every record at once, the API divides the results into smaller pages.

Try changing the URL to:

https://funapi.dev/api/pokemon/v1/pokemon?page=2

You should now see the second page of results.

Filter the Results by Pokémon Type

Suppose you only want Fire-type Pokémon. You can add a query parameter to filter the list:

https://funapi.dev/api/pokemon/v1/pokemon?type=fire

The ?type=fire section tells the API to return records whose type is fire.

You can type the parameter directly into the URL, but Postman also has a Params tab. Add type as the key and fire as the value. Postman will update the URL automatically.

Try a few other values:

  • electric
  • grass
  • water
  • normal
  • rock
  • psychic
  • ghost

Changing a single value and comparing the responses is a simple but useful testing habit. It helps you understand what an endpoint accepts and how different inputs affect the result.

Request One Pokémon

List endpoints are useful, but APIs often provide another endpoint for retrieving one specific record.

Send this request:

GET https://funapi.dev/api/pokemon/v1/pokemon/1

The final 1 is a path parameter. In this case, it is the Pokémon ID.

The response should contain Pikachu:

{
  "id": 1,
  "name": "Pikachu",
  "type": "electric",
  "level": 12,
  "hp": 60,
  "_v": 1
}

Now replace 1 with 4 and send the request again:

GET https://funapi.dev/api/pokemon/v1/pokemon/4

This time, you should receive Squirtle.

Path parameters and query parameters can look similar at first. The easiest way to remember the difference is that a path parameter usually identifies a resource, while a query parameter changes or filters the results.

Break the Request on Purpose

Testing only successful requests gives you half the picture. Real users mistype values, request deleted records, and send incomplete data. A useful API should handle those situations clearly.

Let us request a Pokémon that does not exist:

GET https://funapi.dev/api/pokemon/v1/pokemon/999

Instead of 200 OK, the API should return 404 Not Found:

{
  "error": "Not Found",
  "message": "No Pokémon with id 999."
}

This is the correct behavior. The server did not crash, and it did not pretend the record existed. It returned a suitable status code and a readable explanation.

When testing an API, check both parts. The status code should be correct, and the response body should help the client understand what went wrong.

Catch a New Pokémon with POST

So far, we have only read data. Now let us create a new record.

Create another request in Postman and select POST as the method. Use this URL:

https://funapi.dev/api/pokemon/v1/pokemon

This endpoint is protected, so we need to include a Bearer token.

Open the Authorization tab and choose Bearer Token. Enter:

qa-admin-token

Next, open the Body tab. Select raw, then choose JSON from the format menu.

Paste in the following body:

{
  "name": "Eevee",
  "type": "normal",
  "level": 5,
  "hp": 55
}

Click Send.

A successful request returns 201 Created. The response will contain your new Pokémon:

{
  "id": 9,
  "name": "Eevee",
  "type": "normal",
  "level": 5,
  "hp": 55,
  "_v": 1
}

Your ID may be different. Fun API Playground is a shared sandbox, so other people may have created records before you.

Notice the difference between the two success codes we have seen:

  • 200 OK means the request succeeded.
  • 201 Created means the request succeeded and created a new resource.

That distinction is small, but it becomes important when you start writing automated API tests.

What Happens Without the Token?

Return to the Authorization tab and temporarily remove the Bearer token. Send the POST request again.

You should receive 401 Unauthorized:

{
  "error": "Unauthorized",
  "message": "Missing Bearer token. Use qa-admin-token / qa-viewer-token, or get a JWT from POST /auth/v1/login."
}

Add the token back when you are finished.

It is worth testing invalid authentication separately from missing authentication. For example, try sending this as the token:

not-a-real-token

The API should reject that request too.

These checks confirm that the endpoint is not simply accepting every request it receives.

Add a Few Checks in Postman

Reading the response manually is fine while learning, but it does not scale well. Postman can check the result for you.

Return to the first Pokémon list request and open Scripts → Post-response. Add this script:

pm.test("The request returns 200 OK", function () {
  pm.response.to.have.status(200);
});

pm.test("The response includes a data array", function () {
  const body = pm.response.json();

  pm.expect(body.data).to.be.an("array");
  pm.expect(body.data.length).to.be.greaterThan(0);
});

pm.test("Each Pokémon has an ID and a name", function () {
  const body = pm.response.json();

  body.data.forEach(function (pokemon) {
    pm.expect(pokemon).to.have.property("id");
    pm.expect(pokemon).to.have.property("name");
  });
});

Send the request once more. Postman should display the test results alongside the response.

These tests are deliberately simple. One checks the status code, another checks the general shape of the response, and the last one checks the contents of each record. That is already more reliable than looking at the response and deciding that it “seems fine.”

Try a Pokémon Battle

The API also includes a battle endpoint, which is a more entertaining way to practise another POST request.

Create this request:

POST https://funapi.dev/api/pokemon/v1/battles

Use qa-admin-token as the Bearer token and send this JSON body:

{
  "pokemonAId": 1,
  "pokemonBId": 4
}

The API will simulate a battle between Pikachu and Squirtle. A response might look like this:

{
  "id": 1,
  "pokemonA": "Pikachu",
  "pokemonB": "Squirtle",
  "winner": "Pikachu",
  "turns": 6
}

The winner and number of turns are random, so do not write a test that expects Pikachu to win every time. A better test would check that winner exists and matches one of the two Pokémon in the request.

There is also an easy negative test here. Use the same ID for both values:

{
  "pokemonAId": 1,
  "pokemonBId": 1
}

The API should return 400 Bad Request because a Pokémon cannot battle itself.

Save Time with the Postman Collection

If you would rather explore the complete API than build every request manually, import the ready-made Postman collection:

https://funapi.dev/api/pokemon/v1/postman.json

Click Import in Postman and paste the URL using the link import option.

The collection contains all ten Pokémon API endpoints, organized into Pokémon, trainers, and battles folders. It also includes variables for the base URL and Bearer token.

Once imported, you can experiment with:

  • Listing and filtering Pokémon
  • Finding a random Pokémon
  • Creating and updating records
  • Viewing trainers and their rosters
  • Simulating battles
  • Testing 400, 401, 403, 404, and 412 responses

A Quick Note About the Sandbox

Fun API Playground is designed for testing, and the live data is shared. Records can change or be reset.

That means it is better to find the ID returned by your POST request than to assume every new Pokémon will always have ID 9. This is also good practice for real API automation, where fixed test data often becomes unreliable over time.

Where to Go Next

At this point, you have used GET and POST requests, worked with parameters, read JSON, added authentication, and tested both successful and unsuccessful responses.

A good next challenge is the update endpoint:

PUT https://funapi.dev/api/pokemon/v1/pokemon/1

You can use it to change a Pokémon’s level or HP. The endpoint also supports the If-Match header, which lets you practise optimistic concurrency and the 412 Precondition Failed status.

Do not worry if those terms are unfamiliar right now. The best way to learn them is the same way you learned the requests in this guide: send something, look at the response, change one detail, and try again.

You can find every available request in the Fun API Playground Pokémon documentation.