Send request block in Postman - Deep Dive

Overview - Send request block

What is it?

A Send request block in Postman is a feature that lets you create and send HTTP requests to a server. It helps you test APIs by specifying the method, URL, headers, and body of the request. This block shows the response from the server, so you can check if the API works as expected.

Why it matters

Without the Send request block, testing APIs would be slow and error-prone because you would have to write code or use complex tools. This feature makes it easy to quickly check if an API responds correctly, which saves time and helps catch bugs early. It also allows sharing and reusing tests, improving teamwork and reliability.

Where it fits

Before learning Send request blocks, you should understand basic HTTP concepts like methods (GET, POST), URLs, and headers. After mastering this, you can learn about scripting in Postman, automated testing, and integrating tests into CI/CD pipelines.

Mental Model

Core Idea

A Send request block is like sending a letter to a server and waiting for its reply to check if the message was understood and handled correctly.

Think of it like...

Imagine you want to order a pizza by phone. You call the pizza place (send request), tell them your order (request details), and wait for them to confirm or ask questions (response). The Send request block works the same way with servers.

┌───────────────┐      ┌───────────────┐
│ Send Request  │─────▶│ Server/API    │
│ (method, URL, │      │ processes and │
│ headers, body)│      │ sends reply  │
└───────────────┘      └───────────────┘
          ▲                      │
          │                      ▼
      ┌───────────────┐      ┌───────────────┐
      │ Response      │◀─────│ Server/API    │
      │ (status, body,│      │ reply with    │
      │ headers)      │      │ data or error │
      └───────────────┘      └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding HTTP Requests Basics

Concept: Learn what an HTTP request is and its main parts: method, URL, headers, and body.

An HTTP request is a message sent from a client (like Postman) to a server. It has: - Method: what action to perform (GET to read, POST to create, etc.) - URL: the address of the resource - Headers: extra info like content type - Body: data sent with the request (for POST, PUT) Example: GET https://api.example.com/users sends a request to get user data.

Result

You understand how to describe what you want from a server using HTTP requests.

Knowing the parts of an HTTP request helps you build correct requests and understand what each part does.

2

Foundation

Using Postman Interface to Create Requests

Concept: Learn how to use Postman's interface to set up a request with method, URL, headers, and body.

Open Postman and click 'New Request'. Choose the method (GET, POST, etc.) from the dropdown. Enter the URL in the address bar. Use the 'Headers' tab to add key-value pairs like 'Content-Type: application/json'. Use the 'Body' tab to add data for methods like POST. Then click 'Send' to make the request.

Result

You can create and send a simple HTTP request using Postman’s graphical interface.

Mastering the interface lets you quickly test APIs without writing code.

3

Intermediate

Configuring Request Headers and Body

🤔Before reading on: Do you think headers are always required for every request? Commit to your answer.

Concept: Understand when and how to add headers and body data to requests for proper communication with APIs.

Headers provide metadata like content type or authorization. For example, 'Authorization: Bearer token' lets you access protected APIs. The body carries data for POST or PUT requests, usually in JSON format. You must set 'Content-Type: application/json' header when sending JSON. Incorrect headers or body format can cause errors.

Result

You can customize requests to meet API requirements and avoid common errors.

Knowing how headers and body work prevents failed requests and helps you communicate clearly with servers.

4

Intermediate

Reading and Interpreting Server Responses

🤔Before reading on: Do you think a 200 status code always means the request succeeded as expected? Commit to your answer.

Concept: Learn how to understand the response status, headers, and body to verify API behavior.

After sending a request, Postman shows the response status code (like 200 OK, 404 Not Found), headers, and body. Status codes tell if the request succeeded or failed. The body contains data or error messages. For example, a 200 status with expected JSON means success; a 400 or 500 status means client or server error.

Result

You can judge if an API works correctly by analyzing its response.

Interpreting responses is key to validating API functionality and troubleshooting.

5

Intermediate

Using Variables and Environments in Requests

🤔Before reading on: Do you think variables in Postman requests are only for convenience, or do they affect test reliability? Commit to your answer.

Concept: Learn to use variables and environments to make requests reusable and adaptable.

Variables let you store values like URLs, tokens, or user IDs. Environments group variables for different setups (development, production). Use {{variable_name}} syntax in URLs, headers, or body. This avoids hardcoding and makes tests easier to maintain. For example, {{base_url}}/users changes depending on environment.

Result

You can write flexible requests that work across different servers or users.

Using variables improves test scalability and reduces errors from manual changes.

6

Advanced

Automating Requests with Pre-request Scripts

🤔Before reading on: Do you think pre-request scripts can modify the request before sending, or only after? Commit to your answer.

Concept: Learn how to write scripts that run before sending a request to set dynamic data or headers.

Pre-request scripts are JavaScript code blocks that run before the request is sent. They can generate tokens, set timestamps, or update variables. For example, you can create a timestamp and add it to headers automatically. This helps test APIs that require dynamic data or authentication.

Result

You can automate request preparation, making tests more powerful and realistic.

Pre-request scripts let you handle complex scenarios that static requests cannot cover.

7

Expert

Chaining Requests with Tests and Workflows

🤔Before reading on: Can Postman send multiple requests in sequence where one depends on the previous response? Commit to your answer.

Concept: Learn to connect multiple requests so data flows between them, enabling complex test scenarios.

Postman allows writing tests in JavaScript that run after a response arrives. You can extract data from one response and save it as a variable for the next request. Using Collections and workflows, you can chain requests to simulate real user flows. For example, login first, get a token, then use it in the next request.

Result

You can build realistic, multi-step API tests that mimic real-world usage.

Chaining requests unlocks end-to-end testing and reveals integration issues early.

Under the Hood

When you click Send in Postman, it constructs an HTTP request with the chosen method, URL, headers, and body. Postman uses the underlying network stack of your computer to open a TCP connection to the server, sends the request bytes, and waits for the server's response. The server processes the request, generates a response with a status code, headers, and body, then sends it back. Postman receives this response, parses it, and displays it in the interface.

Why designed this way?

Postman was designed to simplify API testing by hiding complex network details behind a user-friendly interface. It uses standard HTTP protocols to ensure compatibility with all web servers. The design focuses on flexibility (supporting all HTTP methods and headers) and automation (scripts and variables) to cover many testing needs without coding from scratch.

┌───────────────┐
│ User clicks   │
│ 'Send'       │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Postman builds│
│ HTTP request  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Network stack │
│ sends request │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Server/API    │
│ processes    │
│ request      │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Server sends  │
│ HTTP response │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Postman       │
│ receives and  │
│ displays      │
│ response      │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does a 200 OK status code always mean the API request succeeded perfectly? Commit to yes or no.

Common Belief: A 200 OK status code means the request was successful and the response data is correct.

Reality: A 200 status means the server processed the request without error, but the response data might still indicate a problem or unexpected result.

Why it matters: Assuming 200 always means success can cause testers to miss logical errors or incorrect data in API responses.

Quick: Do you think headers are optional for all API requests? Commit to yes or no.

Common Belief: Headers are optional and only needed sometimes; most requests work fine without them.

Reality: Many APIs require specific headers like 'Content-Type' or 'Authorization' to process requests correctly; missing headers cause failures.

Why it matters: Ignoring headers leads to failed requests and wasted debugging time.

Quick: Can you chain multiple requests in Postman so one uses data from the previous? Commit to yes or no.

Common Belief: Postman sends requests independently; you cannot pass data between them automatically.

Reality: Postman supports chaining requests using scripts and variables to pass data from one response to the next request.

Why it matters: Not knowing this limits test coverage and prevents simulating real user flows.

Quick: Does using variables in Postman only make requests easier to read, not affect test reliability? Commit to yes or no.

Common Belief: Variables are just shortcuts for convenience and do not impact test accuracy.

Reality: Variables improve reliability by avoiding hardcoded values that can become outdated or cause errors when environments change.

Why it matters: Ignoring variables leads to brittle tests that break when data or environments change.

Expert Zone

1

Pre-request scripts run in a sandboxed JavaScript environment with limited APIs, so you must know which functions are available.

2

Response parsing in tests can handle different data formats (JSON, XML, plain text), requiring careful checks to avoid runtime errors.

3

Chaining requests with asynchronous calls requires understanding Postman's event-driven execution to avoid timing issues.

When NOT to use

Send request blocks are not suitable for load or performance testing at scale; specialized tools like JMeter or Gatling should be used instead. Also, for very complex workflows, dedicated API testing frameworks with code may be better.

Production Patterns

In real projects, Send request blocks are used inside Collections with environment variables to test multiple API endpoints. Teams automate these with Newman (Postman's CLI) in CI pipelines to catch regressions early. They also use pre-request scripts for token refresh and tests to validate response schemas.

Connections

HTTP Protocol

Builds-on

Understanding HTTP methods, status codes, and headers is essential to correctly using Send request blocks.

Continuous Integration (CI)

Builds-on

Automated API tests using Send request blocks integrate into CI pipelines to ensure code changes do not break APIs.

Customer Service Call Centers

Analogy-based connection

Just like a call center routes and responds to customer calls, Send request blocks route requests and handle responses, showing how communication protocols work in different fields.

Common Pitfalls

#1 Sending a POST request without setting Content-Type header for JSON body.

Wrong approach:

POST https://api.example.com/data
Headers:

Body:
{"name":"John"}

Correct approach:

POST https://api.example.com/data
Headers:
Content-Type: application/json

Body:
{"name":"John"}

Root cause:

Not understanding that servers need Content-Type to parse the body correctly.

#2 Hardcoding URLs and tokens directly in requests without variables.

Wrong approach:

GET https://dev.api.example.com/users
Headers:
Authorization: Bearer abc123token

Correct approach:

GET {{base_url}}/users
Headers:
Authorization: Bearer {{auth_token}}

Root cause:

Lack of knowledge about variables and environments causing brittle tests.

#3 Ignoring response status codes and assuming all responses are successful.

Wrong approach:

Send request and use response body without checking status code.

Correct approach:

Check response status code in tests before processing response body.

Root cause:

Not realizing status codes indicate success or failure and affect test validity.

Key Takeaways

Send request blocks let you easily create and send HTTP requests to test APIs without coding.

Understanding HTTP methods, headers, and body is essential to build correct requests.

Reading and interpreting server responses helps verify API behavior and catch errors.

Using variables and scripts in Postman makes tests flexible, reusable, and powerful.

Chaining requests enables realistic multi-step testing that mimics real user interactions.