API Testing with Postman

Build a Postman collection that tests a REST API with automated scripts.

Introduction

30 Second Summary

Every time you check the weather, scroll social media, or tap a payment button, an API is working behind the scenes. Knowing how to test those APIs is one of the most practical skills you can pick up in tech.

In this project, you will build a complete Postman collection that sends requests to a live REST API. Your collection will validate every response with automated test scripts and share configuration across requests so nothing is hardcoded.

What You'll Build

Picture clicking Send in Postman and watching it fetch blog posts, create a new post, update an existing one, and confirm every response passes its tests with green checkmarks.

By the end of this project, you'll have:

  • GET, POST, and PUT requests that fetch blog posts, filter by author, create new posts, and update existing ones through a live API.
  • Automated test scripts that validate every response the moment you hit Send. Green checkmarks confirm correct status codes and data without manual inspection.
  • A shared base URL variable and collection-level authorization that every request inherits. Change the config in one place, and every request picks up the update.
  • Secret Mission: Chain requests together by capturing a POST response's ID in a collection variable and feeding it into the next PUT request automatically.

Are there any prerequisites?

This project uses the Postman desktop app. If you haven't installed it yet, download it for free from the official Postman downloads page.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Your Collection and Variables

Every request you send in Postman ends up as a loose tab unless you organize it. Without a collection, your requests scatter across your workspace and become impossible to manage as your project grows.

Collections solve this by grouping related requests together. In this step, you will create your first collection, set up a reusable variable for your API's base URL, and fire off your first request to confirm everything works.

In this step, get ready to:
  • Create a Postman collection named "Blog API Explorer".
  • Add a base_url collection variable so you never hardcode the API endpoint.
  • Send your first GET request and see 100 blog posts come back.
Create the Blog API Explorer collection

A collection is a folder that holds all of your related API requests in one place. Think of it like a project folder for everything you will build in this tutorial.

  • In the Postman sidebar, click the + button next to the search bar.
  • Select Collection.
  • Postman creates a new collection with a default name. Click the collection name in the workbench and rename it to Blog API Explorer.
  • Press Enter (Windows) or Return (macOS) to confirm the name.

You should now see Blog API Explorer listed in the sidebar under Collections.

What is a collection?

A Postman collection is a group of saved API requests that you can organize, share, and run together. It can also store authorization settings, variables, and test scripts that apply to every request inside it.

Don't see the + button?

Make sure you are signed in to your Postman account. Collections require a signed-in session. If the sidebar is collapsed, click the sidebar toggle icon at the top left to expand it.

help me find where to create a new collection in Postman

Add the base URL variable

Right now, every request you create would need the full API URL typed out. If that URL ever changes, you would have to update every single request by hand. A collection variable lets you store the URL once and reference it everywhere with {{variable_name}} syntax.

  • Click on Blog API Explorer in the sidebar to open the collection in the workbench.
  • Click the Variables tab.
  • In the first empty row, type base_url under the Variable column.
  • In the same row, type https://jsonplaceholder.typicode.com in the Initial value column.
  • Press Ctrl+S (Windows) or Cmd+S (macOS) to save the collection.

You should see base_url listed in the Variables tab with your URL as its value.

Why use a collection variable instead of typing the URL?

The JSONPlaceholder API lives at https://jsonplaceholder.typicode.com. You will use this base URL in every request throughout the project. Storing it in a variable means you type it once, and if the URL ever changes, you update one variable instead of editing five separate requests.

Don't see the Variables tab?

Make sure you clicked on the collection name in the sidebar, not on a request inside it. The Variables tab appears at the collection level, between Scripts and Runs.

help me find the Variables tab on my Postman collection

Send your first GET request

Your collection is set up and your variable is ready. Time to create your first request and see real data come back from the API.

  • In the sidebar, hover over Blog API Explorer and click the three-dot menu icon (View more actions).
  • Select Add request.
  • A new request tab opens. Click the request name at the top and rename it to Get Posts.
  • Make sure the method dropdown to the left of the URL bar says GET (this is the default).
  • Click in the URL bar and type:
{{base_url}}/posts

What does {{base_url}} do?

When you type {{base_url}} in the URL bar, Postman replaces it with the value you stored in the Variables tab. The actual request goes to https://jsonplaceholder.typicode.com/posts. You can hover over {{base_url}} in the URL bar to confirm Postman resolves it correctly.

Before you hit Send, what do you think the response will look like? Will it be a single object, an array, or an error?

  • Click Send.

The response pane at the bottom populates with data. You should see a 200 OK status and a JSON array of 100 blog post objects. Each post has four fields: userId, id, title, and body.

What is JSONPlaceholder?

JSONPlaceholder is a free fake REST API that simulates real responses. It requires no signup and no API keys. It supports GET, POST, PUT, and DELETE requests, making it perfect for learning how Postman works without worrying about authentication or breaking real data.

Seeing an error instead of 200 OK?

If you see a Could not send request error, check that the URL bar reads exactly {{base_url}}/posts with no extra spaces. Also confirm your base_url variable is saved with the value https://jsonplaceholder.typicode.com (no trailing slash).

If {{base_url}} appears in red in the URL bar, Postman cannot find the variable. Go back to the collection's Variables tab and make sure you saved after adding the variable.

help me debug why my Postman GET request is failing

Your collection is live. You have a reusable base URL variable and a working GET request that pulls 100 blog posts from the API. Next up, you will learn how to filter those posts and retrieve a single post by its ID.

Filter and Retrieve Posts with Params

Your collection is set up with a base_url variable and a working GET request that returns all 100 blog posts. That is a lot of data to sift through.

Real APIs can return thousands of results. You need a way to narrow down those results and pinpoint individual resources. In this step, you will use query parameters to filter posts by author and path variables to retrieve a single post by its ID.

In this step, get ready to:
  • Filter posts by a specific author using query parameters.
  • Retrieve a single post by its ID using a path variable.
  • Inspect request and response headers to understand what metadata travels with every request.
Filter posts by a specific user

Query parameters are key-value pairs appended to a URL after a ? symbol. They tell the API to filter or modify the response without changing which endpoint you are hitting.

  • In the sidebar, hover over the Blog API Explorer collection and click Add request.
  • Name the new request Get Posts by User.
  • Make sure the method is set to GET.
  • Enter {{base_url}}/posts as the request URL.
  • Click the Params tab below the URL bar.
  • In the Query Params section, enter userId as the key.
  • Enter 1 as the value.

What do query parameters do here?

Adding userId=1 tells the JSONPlaceholder API to return only posts written by user 1. You will see the full URL update to {{base_url}}/posts?userId=1 in the URL bar as you type.

Before you hit Send, how many posts do you think will come back? All 100, or fewer?

  • Click Send.

The response returns exactly 10 posts, all with "userId": 1. You went from 100 posts down to 10 with a single query parameter.

Still seeing 100 posts?

  • Check that userId is spelled exactly as shown (lowercase u, uppercase I). Parameter names are case-sensitive.
  • Make sure the checkbox next to the userId parameter in the Params tab is checked. An unchecked parameter is not sent with the request.
  • Confirm your URL reads {{base_url}}/posts and not {{base_url}}/posts/ with a trailing slash.

Help me figure out why my query parameter filter is not working in Postman.

Retrieve a single post with a path variable

Query parameters filter a list. Path variables go one step further by identifying a specific resource. Instead of asking for a filtered list, you ask for one exact item by embedding its ID directly in the URL path.

  • Hover over the Blog API Explorer collection in the sidebar and click Add request.
  • Name the new request Get Single Post.
  • Make sure the method is set to GET.
  • Enter {{base_url}}/posts/:id as the request URL.

What is the colon doing in the URL?

The :id syntax tells Postman this part of the URL is a path variable. Postman automatically adds it to the Params tab under Path Variables so you can set its value without editing the URL directly.

  • Click the Params tab below the URL bar.
  • In the Path Variables section, find the row with id in the key column.
  • Enter 1 as the value.

Before you send this request, what do you expect the response to look like? A list of posts, or a single post object?

  • Click Send.

The response returns a single JSON object with "id": 1 and a status of 200 OK. No array brackets, just one post.

Seeing an empty object or 404?

  • Make sure the URL reads {{base_url}}/posts/:id with a colon before id. Without the colon, Postman treats it as a literal string.
  • Confirm you entered 1 in the Value column next to id in the Path Variables section, not in the Query Params section.

Help me troubleshoot why my path variable request is not returning a single post.

Inspect request and response headers

Every HTTP request and response carries headers alongside the data. Headers are metadata that describe the format of the data, the server that sent it, caching rules, and more. Postman lets you inspect both the headers you sent and the headers the server returned.

  • With the Get Single Post request still open, click the Headers tab in the request section (the upper pane).
  • Notice that Postman automatically includes headers like Accept and User-Agent even though you did not add them. These are default headers Postman sends with every request.
  • Now look at the Headers tab in the response section (the lower pane).
  • Find the Content-Type header in the response headers list.

The response Content-Type header reads application/json; charset=utf-8. This tells you the server is sending back JSON data encoded in UTF-8.

Why do headers matter?

Headers are how the client and server agree on the rules of the conversation. The Content-Type header is especially important because it tells the receiving side how to interpret the data. If the server sent XML but your app expected JSON, everything would break.

You now have three GET requests in your collection. One fetches all posts, one filters by author, and one retrieves a single post by ID. Next up, you will learn how to send data to the API using POST and PUT requests.

Create and Update Posts with Body and Headers

You can now filter posts by author and retrieve a single post by its ID. Every request so far has been a GET request, which only reads data from the API.

To send data to an API, you need POST and PUT requests that carry a JSON body. Without the right body format and headers, the API will reject your data or misinterpret it.

In this step, get ready to:
  • Create a POST request that sends a JSON body to add a new blog post.
  • Create a PUT request that sends a JSON body to update an existing post.
  • Inspect the Content-Type header that Postman sets automatically when you choose JSON.
Create a POST request to add a new post

A GET request asks the API for data. A POST request does the opposite. It sends new data to the API so the server can create a resource from it.

  • Hover over Blog API Explorer in the sidebar and click Add a request.
  • Rename the new request to Create Post.
  • Click the method dropdown (currently set to GET) and select POST.
  • Enter {{base_url}}/posts in the URL field.
  • Click the Body tab below the URL field.
  • Select raw from the body type options.
  • From the format dropdown to the right of raw, select JSON.
  • Paste the following JSON into the body text area:
{
    "title": "My First Post",
    "body": "This is the content of my post.",
    "userId": 1
}

What does this JSON body do?

This JSON object represents the new blog post you want to create. The API reads each field to build the resource on the server.

  • title sets the headline of the post.
  • body holds the main content.
  • userId identifies who authored the post.

Before you click Send, what status code do you expect back? Your GET requests returned 200 OK. Will creating something new return the same code?

  • Click Send.

The response pane shows 201 Created. That is the HTTP status code for "a new resource was successfully created." The response body contains your post data with an id of 101.

Why id 101?

JSONPlaceholder's dataset already contains 100 posts. When you create a new one, the API simulates assigning the next available ID, which is 101. The post is not actually saved on the server, but the response shape is identical to what a real API would return.

Inspect the auto-generated Content-Type header

When you selected raw and JSON in the Body tab, Postman did something behind the scenes. It automatically added a request header telling the API what format the body is in.

  • Click the Headers tab in the request area (above the response, next to the Body tab you were just using).
  • Click hidden to reveal the headers Postman added automatically.

You should see a Content-Type header with the value application/json.

What is the Content-Type header?

The Content-Type header tells the API what format the request body is in. Without it, the server would not know whether the body is JSON, plain text, or something else entirely.

Postman sets this header automatically when you choose a body format. You did not have to type it yourself.

Seeing 404 or an unexpected response?

  • Double-check the URL reads {{base_url}}/posts with no trailing slash or extra path segments.
  • Confirm the method dropdown shows POST, not GET.
  • Make sure you selected raw and JSON in the Body tab before pasting the JSON.
  • help me troubleshoot my POST request in Postman
Create a PUT request to update an existing post

A POST request creates a brand-new resource. A PUT request replaces an existing resource with updated data. You target the specific resource by including its ID in the URL.

  • Hover over Blog API Explorer in the sidebar and click Add a request.
  • Rename the request to Update Post.
  • Click the method dropdown and select PUT.
  • Enter {{base_url}}/posts/:id in the URL field.
  • Click the Params tab and find the Path Variables section at the bottom.
  • Set the value of id to 1.
  • Click the Body tab.
  • Select raw from the body type options.
  • From the format dropdown, select JSON.
  • Paste the following JSON into the body text area:
{
    "id": 1,
    "title": "Updated Title",
    "body": "This content has been updated.",
    "userId": 1
}

What is different about this JSON body?

A PUT request sends the full updated resource, not just the fields that changed. That is why the body includes id and userId alongside the new title and body.

Before you hit Send, think about what status code you expect. This is an update, not a creation. Will the API return 201 Created again, or something different?

  • Click Send.

The response shows 200 OK. The API successfully updated the resource. In the response body, you can see the title now reads Updated Title.

  • Click the Headers tab in the request area and click hidden to confirm the Content-Type: application/json header was auto-set here too.

Seeing a 404 or the title did not change?

  • Confirm the URL reads {{base_url}}/posts/:id and that the path variable id is set to 1 in the Params tab.
  • Make sure the method dropdown shows PUT, not GET or POST.
  • Check that the JSON body includes the id field set to 1. A missing or mismatched ID can cause unexpected results.
  • help me troubleshoot my PUT request in Postman

You can now read, create, and update data through an API. Your requests work, but they have no authorization. Next up, you will configure auth at the collection level so every request inherits it automatically.

Configure Authorization at the Collection Level

Your collection can read, create, and update blog posts through GET, POST, and PUT requests. Every request hits the right endpoint and returns the data you expect.

Those requests carry no credentials at all. Real-world APIs require authentication, and configuring it on every single request is repetitive and fragile. Postman lets you set authorization once at the collection level so every request inherits it automatically.

In this step, get ready to:
  • Configure API Key authorization on the collection and verify it appears in request headers.
  • Confirm that individual requests inherit auth from the collection automatically.
  • Switch the collection to Bearer Token authorization and verify the updated header.
Set up API Key authorization on the collection

Right now, your five requests work, but they carry zero credentials. Any API that enforces authentication would reject them outright.

  • Click on the Blog API Explorer collection name in the sidebar.
  • Select the Authorization tab in the collection panel that opens.
  • Click the Auth Type dropdown and select API Key.
  • Enter X-Api-Key in the Key field.
  • Enter my-demo-api-key-12345 in the Value field.
  • Click the Add to dropdown and select Header.
  • Press Cmd+S (macOS) or Ctrl+S (Windows) to save the collection.

Why configure auth at the collection level?

Setting auth on the collection means every request inside it inherits the same credentials automatically. You configure once, and all current and future requests pick it up.

If you set auth on each request individually, you would need to update every single one whenever credentials change. Collection-level auth keeps your setup DRY and maintainable.

What is API Key authorization?

API Key auth sends a named key-value pair with every request, typically as a header. The server checks this key to identify and authorize the caller.

You are using dummy values here because JSONPlaceholder does not require real authentication. The goal is to see how Postman attaches auth headers to outgoing requests.

Verify that requests inherit auth automatically

You configured auth on the collection, but does each request actually pick it up? Time to check.

  • Click on the Get Single Post request in the sidebar to open it.
  • Select the Authorization tab for this request.
  • Confirm the Auth Type dropdown shows Inherit auth from parent.

What does 'Inherit auth from parent' mean?

Every new request created inside a collection defaults to inheriting the collection's auth settings. You configure credentials in one place and all requests pick them up automatically.

If a specific request ever needs different auth, you can override it on that request's Authorization tab by selecting a different auth type.

  • Click Send to fire the request.
  • Select the Headers tab in the request panel (not the response).
  • Click hidden at the top of the Headers tab to reveal the auto-generated headers.

You should see X-Api-Key: my-demo-api-key-12345 listed among the hidden headers. The request still returns status 200 OK because JSONPlaceholder accepts all requests regardless of auth.

The important thing is the header itself. It proves your collection-level API Key auth is being sent with every request.

Don't see the X-Api-Key header?

Make sure you saved the collection after configuring auth. Unsaved changes are not inherited by requests.

Confirm you clicked hidden at the top of the request's Headers tab. The auth header is auto-generated, so it only appears in the hidden section.

Check that the request's Authorization tab still shows Inherit auth from parent. If it shows a different auth type, switch it back.

Why isn't my API Key header showing up in Postman's hidden headers?

Switch to Bearer Token authorization

API Key auth is one approach. Many modern APIs use Bearer Token authorization instead, where a token is sent in the Authorization header. Switching the collection's auth type updates every inheriting request in one move.

  • Click on the Blog API Explorer collection name in the sidebar to return to the collection settings.
  • Select the Authorization tab.
  • Click the Auth Type dropdown and select Bearer Token.
  • Enter my-demo-bearer-token-67890 in the Token field.
  • Press Cmd+S (macOS) or Ctrl+S (Windows) to save the collection.

What is Bearer Token authorization?

Bearer Token auth sends a token in the Authorization header using the format Bearer <token>. Many modern APIs issue these tokens through an OAuth flow.

The server validates the token to authenticate and authorize the request. Postman formats the header for you automatically when you choose this auth type.

Before you send the request, what do you expect to see in the hidden headers? Will the API Key header still be there, or will something different appear?

  • Return to the Get Single Post request by clicking it in the sidebar.
  • Click Send.
  • Select the Headers tab and click hidden to reveal the auto-generated headers.

The hidden headers now show Authorization: Bearer my-demo-bearer-token-67890. The API Key header is gone because you changed the collection's auth type to Bearer Token.

The status remains 200 OK because JSONPlaceholder accepts all requests. The header proves the auth mechanism is working.

Don't see the Authorization header?

Make sure you saved the collection after switching to Bearer Token. Click the collection name and press Cmd+S (macOS) or Ctrl+S (Windows) to save.

Confirm you selected Bearer Token from the Auth Type dropdown and entered the token in the Token field. If the field is empty, the header will not be sent.

Why isn't my Bearer Token header showing in Postman's hidden headers?

Your collection now has authorization configured and every request inherits it automatically. Next up, you will write post-response test scripts that validate your API responses without any manual eyeballing.

Write Post-Response Test Scripts

Your collection now has authorization configured at the collection level, with every request inheriting auth automatically. Next, you'll add automated testing so Postman validates every response for you.

So far, you've been manually checking status codes and response data by scanning the response panel. That works for a handful of requests, but it does not scale. Post-response scripts let you write checks that run automatically every time you send a request, catching issues instantly.

In this step, get ready to:
  • Add test scripts to the Get Single Post request that validate the status code and response body.
  • Add test scripts to the Create Post request that check the status and response title.
  • Add test scripts to the Get Posts by User request that verify the response structure and data.
Add test scripts to the Get Single Post request

Post-response scripts are JavaScript snippets that run automatically after Postman receives a response. You write assertions inside them, and Postman reports pass or fail in a dedicated tab.

  • Click the Get Single Post request in your collection sidebar to open it.
  • Click the Scripts tab in the request panel, then click Post-response.
  • Paste the following script into the code editor:
// Check that the response status is 200 OK
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});

// Verify the response contains the correct post
pm.test("Post has correct id", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.id).to.eql(1);
});

What does this script do?

Each pm.test() block defines a named test. Postman runs the function inside it and marks the test as passed or failed.

  • The first test uses pm.response.to.have.status(200) to confirm the server returned a 200 OK status code.
  • The second test calls pm.response.json() to parse the response body into a JavaScript object. Then pm.expect(jsonData.id).to.eql(1) asserts the returned post has an id of 1.

Before you send this request, what do you expect the Test Results tab to show? How many tests should pass?

  • Click Send.
  • In the response panel, click the Test Results tab.

You should see 2/2 tests passing with green checkmarks. Both "Status code is 200" and "Post has correct id" show as passed.

Tests not showing up?

  • Make sure you pasted the script into the Post-response tab, not the Pre-request tab. Both live under Scripts, but only Post-response runs after the response arrives.
  • If you see a syntax error, check that the closing braces and parentheses match. Each pm.test() block ends with });.
  • Still stuck? Why are my Postman post-response tests not appearing in the Test Results tab?
Add test scripts to the Create Post request
  • Click the Create Post request in your collection sidebar.
  • Click Scripts then Post-response.
  • Paste the following script into the code editor:
// Check that the response status is 201 Created
pm.test("Status code is 201", function () {
    pm.response.to.have.status(201);
});

// Verify the response title matches what we sent
pm.test("Post title matches", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.title).to.eql("My First Post");
});

What does this script do?

This script follows the same pattern as the previous one, but checks for a 201 status code instead of 200. A 201 means the server created a new resource.

The second test parses the response and checks that the title field matches "My First Post". This confirms the API echoed back exactly what you sent.

  • Click Send.
  • Click the Test Results tab in the response panel. You should see 2/2 tests passing with green checkmarks.

Seeing a failing test?

  • If "Post title matches" fails, check that the JSON body you set up earlier still has "title": "My First Post" in the Body tab. The test checks for an exact match, so capitalization and spacing matter.
  • If "Status code is 201" fails, make sure the request method is set to POST (not GET or PUT) in the method dropdown.
  • Need more help? My Create Post test script is failing in Postman. How do I fix it?
Add test scripts to the Get Posts by User request

The previous two scripts checked a single value in the response. This script goes further by validating every item in an array.

  • Click the Get Posts by User request in your collection sidebar.
  • Click Scripts then Post-response.
  • Paste the following script into the code editor:
// Check that the response is an array of posts
pm.test("Response is an array", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.be.an("array");
});

// Verify every post in the array belongs to user 1
pm.test("All posts belong to userId 1", function () {
    const jsonData = pm.response.json();
    jsonData.forEach(function (post) {
        pm.expect(post.userId).to.eql(1);
    });
});

What does this script do?

The first test asserts the response is an array, not a single object. This catches cases where the API returns an unexpected shape.

The second test loops through every post in the array with forEach and asserts each one has userId equal to 1. If even one post belongs to a different user, the test fails. This is a powerful pattern for validating filtered results.

Before you send this request, do you think all 10 posts will pass the userId check?

  • Click Send.
  • Click the Test Results tab. You should see 2/2 tests passing with green checkmarks.

All three requests now validate themselves automatically. The Get Single Post request shows 2 passing tests, the Create Post request shows 2 passing tests, and the Get Posts by User request shows 2 passing tests.

All posts belong to userId 1 is failing?

  • Check the Params tab and confirm the userId query parameter is set to 1 and its checkbox is enabled. If the parameter is unchecked, Postman does not send it with the request.
  • Make sure you pasted the script into the correct request. The Get Posts by User request is the one with the userId query parameter, not the plain Get Posts request.
  • Still stuck? My forEach test in Postman is failing when checking userId on filtered posts. How do I debug this?

✔️ Awesome, I've got everything!

Great. All three requests now have post-response scripts that validate themselves every time you click Send.

ⓧ I'd like to double check my scripts

Scroll up and confirm each request's script matches what you pasted. Here is a summary of what each request should have:

  • Get Single Post: Two pm.test blocks. "Status code is 200" checks pm.response.to.have.status(200). "Post has correct id" checks pm.expect(jsonData.id).to.eql(1).
  • Create Post: Two pm.test blocks. "Status code is 201" checks pm.response.to.have.status(201). "Post title matches" checks pm.expect(jsonData.title).to.eql("My First Post").
  • Get Posts by User: Two pm.test blocks. "Response is an array" checks pm.expect(jsonData).to.be.an("array"). "All posts belong to userId 1" loops through each post and checks pm.expect(post.userId).to.eql(1).

Every request in your collection now tests itself automatically. No more eyeballing status codes and scrolling through response bodies. Up next, you'll take this even further by chaining requests together so one request's output feeds directly into the next.

Secret mission

Chain Requests with Pre-Request Scripts and Variables

In real API workflows, one request's output becomes the next request's input. Your challenge is to capture the post ID from a Create Post response, store it in a collection variable, and automatically feed it into a follow-up PUT request. This is how professional API testers build automated, multi-step workflows.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely in Postman using a free public API, so there are no ongoing costs or cloud resources to worry about. Decide whether to keep your collection for future reference or delete it entirely.

Resources you used:

  • Blog API Explorer collection in Postman (with all requests, variables, authorization, and test scripts).

Keep everything running

No action needed. Choose this if you want to keep the collection for reference or continue experimenting with new requests and test scripts.

  • Your Blog API Explorer collection stays in your Postman workspace and costs nothing to keep.
  • JSONPlaceholder is a free public API, so any future requests you send are also free.

Pause - I'll come back to this later

There is nothing to pause for this project. Your Postman collection sits idle until you open it again, using no resources.

  • You can close the Postman app. Your collection is saved to your Postman account and will be there when you reopen it.

Delete - I don't want to use this again

Remove the collection entirely from your Postman workspace.

  • In the Postman sidebar, click View more actions (the three-dot icon) next to the Blog API Explorer collection.
  • Click Delete.
  • When prompted, type delete in the confirmation field, then click Delete Collection.

Nice Work!

Nice Work!

You just built a complete API testing collection in Postman from scratch. Your Blog API Explorer sends requests, validates responses, and manages authorization, all without a single URL hardcoded.

You've learned how to:

  • Built GET, POST, and PUT requests that use collection variables, query parameters, path variables, and raw JSON bodies to interact with a REST API.
  • Configured authorization at the collection level so every request inherits auth automatically, and inspected hidden headers to confirm the credentials are being sent.
  • Wrote post-response test scripts using pm.test, pm.expect, and pm.response.json() to automatically validate status codes, response body fields, and array contents.
  • Secret Mission: Completed an optional challenge to push your API testing skills further.

Ready to quiz yourself?