Cheatsheet Postman

GET     // fetch data (no body)
POST    // create a resource
PUT     // replace the whole resource
PATCH   // partial update
DELETE  // remove a resource
HEAD    // headers only (no body)
OPTIONS // allowed methods

// Select in AS dropdown to the
// left of the URL. Example:
// POST https://api.example.com/users

Pick the method in the dropdown next to the URL. GET reads, POST creates, PUT replaces, PATCH updates partially, DELETE removes. HEAD and OPTIONS are for inspection.

// "Params" tab — key/value pairs:
//   page = 1
//   limit = 10
//   q = postman

// URL generated automatically:
// https://api.example.com/users
//   ?page=1&limit=10&q=postman

// Disable a param: uncheck
// the checkbox (do not delete)

// Postman automatically encodes
// spaces and special characters

Query parameters are set in the Params tab — the URL is built automatically. Disable with the checkbox instead of deleting. Postman does automatic URL encoding of special characters.

// "Headers" tab — key/value pairs:
Content-Type: application/json
Accept: application/json
Authorization: Bearer {{token}}
X-API-Key: {{api_key}}

// Automatically generated headers
// appear in gray (hidden)
// under "hidden headers"

// Disable a header:
//   uncheck the checkbox
// Bulk edit: "bulk edit" button
//   to paste several lines

Headers are set in the Headers tab the key/value pairs. Content-Type indicates the body format. Automatic headers (like User-Agent) stay hidden. Use bulk edit to paste several at once.

// URL with a path variable:
// https://api.example.com/users/:id

// When typing ":id", it appears
// automatically in the Params tab
// ("Path Variables" section):
//   id = 42

// Result:
// https://api.example.com/users/42

// Multiple:
// /users/:userId/posts/:postId

Path variables use :name in the URL (e.g. /users/:id). Postman adds them automatically to the Params tab in the Path Variables section. More readable than query params for identifiers.

// Body tab > raw > JSON

{
  "name": "Anna",
  "age": 30,
  "active": true,
  "tags": ["dev", "api"]
}

// Ctrl+Shift+F formats the JSON
// Postman validates the syntax and
// warns if there are errors

// The Content-Type header is
// added automatically

In the Body tab choose raw + JSON. Format with Ctrl+Shift+F — Postman validates the syntax. The Content-Type: application/json header is added automatically.

// After Send, the panel shows:
//   Status: 200 OK (green)
//   4xx orange | 5xx red
//   Time: 145 ms
//   Size: 2.3 KB

// Response tabs:
//   Body    → Pretty | Raw | Preview
//   Cookies → received cookies
//   Headers → response headers
//   Tests   → test results

// "Save the example" stores the
// response the an example (mocks)

The response shows status (green 2xx, orange 4xx, red 5xx), time and size. Tabs: Body (Pretty/Raw/Preview), Cookies, Headers and Tests. Save the example stores responses for mocks.

// Body > form-data (multipart):
//   name: Anna
//   file: [Select Files]
//   (change the type to "File"
//    in the row's dropdown)

// Body > x-www-form-urlencoded:
//   name=Anna&age=30
//   (classic form format)

// Body > binary:
//   send a raw file
//   (image, PDF, etc.)

form-data sends multipart (with files — change the row to type File). x-www-form-urlencoded is the classic form format. binary sends raw files (images, PDFs).

// "Cookies" link (below Send)
// shows the cookie jar per domain

// Postman keeps cookies between
// requests automatically
// (like a browser)

// Example: a login stores the
// session cookie, and the next
// requests send it on their own

// Delete cookies:
//   Cookies > domain > X
//   (useful to test logout)

Postman manages cookies automatically like a browser — a login stores the session cookie and the next requests send it. Manage the cookie jar in the Cookies link (delete to test sessionless scenarios).

// Ctrl+Shift+N or
// Collections > "+" > Collection

// Name: "Users API"
// Description (optional, markdown)

// Save requests in the collection:
//   Ctrl+S on the open request
//   or drag the tab

// A collection groups all the
// requests of an API/project

A collection groups all the requests of a project. Create one with Ctrl+Shift+N and save requests with Ctrl+S or by dragging tabs. The description supports markdown.

// Flows (sidebar) > Create Flow

// Available blocks:
//   Request  → calls a request
//   Delay    → waits X seconds
//   Condition → if/else by value
//   Set Variable

// Connect blocks with arrows to
// create visual workflows:
//   Login > condition (200?)
//   > Get data > Notify

// Run manually or schedule

Flows create visual workflows by connecting blocks: Request, Delay, Condition, Set Variable. Ideal for sequences with logic (login → condition → action) without writing code.

// Collection > "..." > Add Folder

// Recommended structure:
// Users API/
//   Auth/
//     Login, Logout, Refresh
//   Users/
//     List, Create, Update
//   Admin/
//     Statistics

// Drag to move requests
// between folders. Folders can
// have their own auth, tests and
// variables (inherited by children)

Organize with folders per resource (Auth, Users, Admin). Folders can have their own auth, tests and variables that child requests inherit. Drag to reorganize.

// Share:
//   Collection > Share
//   > Via workspace (team)
//   > Via public link (view-only)

// Version with Git:
//   Settings > Connected to Git
//   (GitHub, GitLab, Bitbucket)
//   Each change = commit

// Fork:
//   Fork Collection > change
//   > Merge back (like Git)

Share via workspace (team) or public link (view-only). Connect to Git to version changes the commits. Fork + merge work like in Git — change without affecting the original.

// Import (Import button):
//   - JSON file (Postman v2.1)
//   - OpenAPI / Swagger (URL or file)
//   - cURL (paste the command)
//   - HAR, WSDL, RAML

// Export:
//   Collection > "..." > Export
//   > Collection v2.1 (JSON)

// cURL to Postman:
//   Import > Raw text > paste:
//   curl -X GET https://api...

Import from OpenAPI/Swagger, cURL, HAR and JSON. Export the Collection v2.1 (JSON) to share or version. Pasting a cURL command converts it into a request automatically.

// Collection > "..." > View Docs

// Generates automatic documentation:
//   - All the requests
//   - Parameters and bodies
//   - Response examples
//   - Test scripts

// Publish:
//   Docs > Publish (public link)
//   postman.com/docs/...

// Improve with descriptions on
// requests and saved "examples"

Postman generates automatic documentation from the collection (requests, params, examples). Publish with one click in Docs > Publish. Descriptions and saved examples enrich the documentation.

// Collection > "Run" button
// (or Runner in the sidebar)

// Configuration:
//   Environment: Dev
//   Iterations: 3 (repetitions)
//   Delay: 200 ms between requests
//   Data: CSV/JSON file

// Runs all the requests in
// sequence and shows a report
// with passed/failed tests

The Runner executes the whole collection in sequence with tests. Configure iterations (repetitions), delay between requests and a data file (CSV/JSON). It shows a report with passed/failed tests.

// Collection > Edit > Variables

// Example:
//   base_url = https://api.example.com
//   version  = v2

// Use in any request:
// {{base_url}}/{{version}}/users

// All the requests in the collection
// share these variables

// Change here and it changes everywhere

Collection variables are set in Edit > Variables and become available in every request via {{name}}. Perfect for base_url — change it in one place and everything updates.

// Environments (sidebar) > "+"

// "Dev" environment:
//   base_url = http://localhost:8000
//   api_key  = dev-key-123

// "Prod" environment:
//   base_url = https://api.example.com
//   api_key  = prod-key-xyz

// Activate: dropdown in the top
// right corner (eye = preview)

Create one environment per context (Dev, Staging, Prod) with its own variables. Activate it in the top-right dropdown. The same request works in every environment without changing anything.

// "Pre-request" tab — runs
// BEFORE each request:

// Generate a timestamp:
pm.environment.set("ts", Date.now());

// Sign the request (HMAC):
const signature = CryptoJS.HmacSHA256(
  pm.request.url.toString(),
  pm.environment.get("secret")
);
pm.environment.set("sign", signature);

// Useful for: tokens, hashes,
// dynamic data, cleanup

The Pre-request Script runs before the request — ideal for generating timestamps, HMAC signatures or preparing data. Use pm.environment.set() to store values used in the request.

// Syntax: {{variable_name}}

// URL:
// {{base_url}}/users/{{user_id}}

// Headers:
// Authorization: Bearer {{token}}

// Body:
// { "api_key": "{{api_key}}" }

// Active variables appear in
// orange; missing ones in red

Variables use the {{name}} syntax in any field (URL, headers, body). They appear in orange when resolved and in red when they don't exist. Hover to see the current value.

// Environment > Edit > Pre-request
// and > Tests (they run on ALL the
// requests of that environment)

// Example (env Pre-request):
// make sure there is a token before
// any request:
if (!pm.environment.get("token")) {
  console.log("⚠️ No token!");
}

// Avoids repeating the same scripts
// in every request of the collection

Environments also have Pre-request and Tests that run on every request of that environment. Perfect for global validations (e.g. ensuring a token exists) without repeating code in each request.

// Resolution order (highest wins):
// 1. Data       (Runner file)
// 2. Local      (pm.variables.set)
// 3. Environment (active environment)
// 4. Collection (collection variables)
// 5. Global     (visible everywhere)

// Example: if "base_url" exists
// in the environment AND in the
// collection, the environment wins

// Debug: the Console (Ctrl+Alt+C)
// shows which value was used

Precedence (highest wins): Data > Local > Environment > Collection > Global. If the same variable exists in several scopes, the most specific one wins. The Console shows the value used.

// Dropdown in the top right corner
// > select: Dev | Staging | Prod

// Instant switching:
//   same request, different URLs

// "No Environment" = only
// collection/global variables active

// Eye icon (preview):
//   shows the environment values
//   without activating it

// Duplicate environment:
//   "..." > Duplicate (base for Prod)

Switch environments in the top-right dropdown — the same request starts pointing to another URL. The eye icon shows values without activating. Duplicate an environment to create variants quickly.

// Automatic placeholders:
{{$guid}}          // UUID v4
{{$timestamp}}     // epoch seconds
{{$randomInt}}     // 0-1000
{{$randomEmail}}   // random email
{{$randomFullName}}
{{$randomUUID}}
{{$randomPassword}}
{{$randomLoremWord}}

// Useful in test bodies:
// { "email": "{{$randomEmail}}" }

Dynamic variables ({{$guid}}, {{$timestamp}}, {{$randomEmail}}...) generate automatic values on every run. Ideal for creating unique test data without scripts.

// In scripts (Pre-request/Tests):

// Read (respects the scope):
const url = pm.variables.get("base_url");

// Store:
pm.environment.set("token", "abc123");
pm.collectionVariables.set("total", 42);
pm.globals.set("debug", true);

// Delete:
pm.environment.unset("token");

// pm.variables.get() searches all
// the scopes automatically

In scripts: pm.variables.get() reads respecting the scope; pm.environment.set(), pm.collectionVariables.set() and pm.globals.set() store in specific scopes. unset() deletes.

// "Tests" tab — runs AFTER
// receiving the response:

pm.test("Status is 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Has body", function () {
  pm.response.to.have.body();
});

// Results appear in the "Tests"
// tab of the response panel

Tests are written in the Tests tab with pm.test() — each one appears the passed/failed in the response panel. They use the Chai syntax (expect/should). They run after each response.

// Right panel of the Tests tab:
// "Snippets" — ready-made blocks

// Most used:
// - Status code: Code is 200
// - Response body: Contains string
// - Response body: JSON value check
// - Response time < 200ms
// - Status: Successful POST

// Click a snippet and the code
// is inserted — adjust the values

// The search on top filters the list

Snippets (right panel of the Tests tab) are ready-to-use test blocks: status 200, JSON value check, response time, etc. Click to insert and adjust the values — ideal for getting started fast.

// Status:
pm.test("OK", () => {
  pm.response.to.have.status(200);
});

// Status among several:
pm.test("Success", () => {
  pm.expect(pm.response.code)
    .to.be.oneOf([200, 201]);
});

// Headers:
pm.test("Is JSON", () => {
  pm.response.to.have
    .header("Content-Type");
});

// Response time:
pm.test("Fast", () => {
  pm.expect(pm.response.responseTime)
    .to.be.below(500);
});

Common asserts: to.have.status() checks the code, oneOf([200, 201]) accepts several, to.have.header() confirms headers and responseTime measures performance in ms.

// Validates the STRUCTURE of the
// response with tv4 (bundled in Postman):

const schema = {
  "type": "object",
  "required": ["id", "name"],
  "properties": {
    "id": { "type": "number" },
    "name": { "type": "string" },
    "active": { "type": "boolean" }
  }
};

pm.test("Valid schema", () => {
  pm.expect(
    tv4.validate(pm.response.json(), schema)
  ).to.be.true;
});

Schema validation confirms the structure (types, required fields) instead of exact values. Use tv4 (bundled in Postman) with JSON Schema. It detects breaking changes in the API.

const json = pm.response.json();

pm.test("Correct name", () => {
  pm.expect(json.name).to.eql("Anna");
});

pm.test("Has numeric id", () => {
  pm.expect(json.id).to.be.a("number");
});

pm.test("Non-empty list", () => {
  pm.expect(json.items)
    .to.have.lengthOf.above(0);
});

pm.test("Field exists", () => {
  pm.expect(json)
    .to.have.property("email");
});

Convert the response with pm.response.json() and validate fields: to.eql() compares values, to.be.a("number") checks types, lengthOf.above(0) confirms non-empty arrays, to.have.property() checks existence.

// data.csv file:
// name,email
// Anna,ana@mail.com
// Ray,rui@mail.com

// In the Runner: Data > select CSV

// In the request body:
// { "name": "{{name}}",
//   "email": "{{email}}" }

// Each iteration uses one line
// of the file (2 lines = 2 runs)

// pm.iterationData.get("name")
// reads the current value in scripts

Data-driven testing: create a CSV/JSON with one line per scenario and select it in the Runner. Each iteration uses different values via {{column}}. In scripts, read with pm.iterationData.get().

// Request 1 (Login) — Tests tab:
const json = pm.response.json();
pm.environment.set("token", json.token);
pm.environment.set("user_id", json.id);

// Request 2 (Profile):
// URL: {{base_url}}/users/{{user_id}}
// Header:
//   Authorization: Bearer {{token}}

// The Runner executes in sequence
// and the token flows automatically

Essential pattern: in the login test, store the token with pm.environment.set(). The next requests use {{token}} in the header. In the Runner, data flows automatically between requests.

// Presents the response the
// custom HTML:

const template = `
  <h2>{{name}}</h2>
  <p>Email: {{email}}</p>
  <table>
    {{#each items}}
      <tr><td>{{this}}</td></tr>
    {{/each}}
  </table>
`;

pm.visualizer.set(template, {
  name: "Anna",
  email: "ana@mail.com",
  items: ["a", "b", "c"]
});

// See it in: Body > Visualize

The Visualizer renders the response the custom HTML with Handlebars templates. Set the template with pm.visualizer.set() in Tests and see the result in the Visualize tab. Great for readable reports.

// Request "Authorization" tab

// Type: "No Auth"
//   (no authentication)

// Type: "Inherit auth from parent"
//   uses the auth of the folder or
//   collection (default)

// Set auth on the collection:
//   Collection > Authorization
//   > Bearer Token {{token}}
//   All the requests inherit it!

// Change the token in one place

No Auth sends without credentials. Inherit auth from parent (default) uses the auth of the folder or collection. Setting auth at the collection level applies it to every request — change the token in one place.

// Authorization > Type: OAuth 2.0
// Grant Type: Authorization Code
//
// Auth URL:  https://auth.ex.com/authorize
// Token URL: https://auth.ex.com/token
// Client ID:     {{client_id}}
// Client Secret: {{client_secret}}
// Scope: read write
//
// "Get New Access Token" opens
// the browser to log in and gets
// the token automatically

OAuth 2.0 supports several grant types (Authorization Code, Client Credentials, etc.). Fill in Auth URL, Token URL, Client ID/Secret and click Get New Access Token — Postman handles the whole flow.

// Authorization > Type: Bearer Token
// Token: {{token}}

// Header generated automatically:
// Authorization: Bearer eyJhbG...

// Typical flow:
// 1. Login request (POST)
// 2. Test stores:
//    pm.environment.set("token",
//      pm.response.json().token)
// 3. The remaining requests use
//    Bearer {{token}}

Bearer Token is the most common method in modern APIs (JWT). Put {{token}} in the field and the Authorization: Bearer ... header is generated automatically. Combine with the login test that stores the token.

// OAuth 1.0 (signature, no token):
//   Consumer Key / Secret
//   Token / Token Secret
//   Signature Method: HMAC-SHA1
//   (used by old APIs,
//    e.g. Twitter v1)

// Digest Auth:
//   Username / Password
//   (negotiates challenge-response
//    with the server — safer than
//    Basic, without sending the pass)

// Both generate automatic headers

OAuth 1.0 signs requests with HMAC-SHA1 (old APIs). Digest Auth uses challenge-response without sending the password in the clear — safer than Basic. Postman generates the complex headers automatically.

// Authorization > Type: Basic Auth
// Username: {{user}}
// Password: {{pass}}

// Generated header:
// Authorization: Basic dXNlcjpwYXNz
// (base64 of "user:pass")

// Warning: base64 is NOT
// encryption — always use it
// over HTTPS in production

Basic Auth sends username and password encoded in base64 in the Authorization header. Simple but insecure without HTTPS — base64 is encoding, not encryption.

// Collection > Authorization:
//   Type: Bearer Token
//   Token: {{token}}

// Collection > Pre-request Script:
const tokenOk = pm.environment.get("token");
if (!tokenOk) {
  pm.sendRequest({
    url: pm.variables.get("base_url")
      + "/login",
    method: "POST",
    body: { mode: "raw",
      raw: JSON.stringify({
        email: "ana@mail.com",
        pass: "123" }) }
  }, (err, res) => {
    pm.environment.set("token",
      res.json().token);
  });
}

Full automation: in the collection Pre-request, pm.sendRequest() logs in and stores the token if it doesn't exist. All the requests become authenticated automatically without manual intervention.

// Authorization > Type: API Key
// Key:   X-API-KEY
// Value: {{api_key}}
// Add to: Header (or Query Params)

// Generated header:
// X-API-KEY: abc123xyz

// Or in query (less secure):
// ?X-API-KEY=abc123xyz

// Store the key in an environment
// variable (never hardcoded)

API Key sends the key in a custom header (e.g. X-API-KEY) or in query params. Choose Header (more secure). Always store the value in an environment variable, never hardcoded.

// Test protected endpoints:

pm.test("No token = 401", () => {
  pm.response.to.have.status(401);
});

// With an invalid token:
pm.test("Invalid token = 403", () => {
  pm.response.to.have.status(403);
});

// Check JWT claims:
const payload = JSON.parse(
  atob(pm.environment.get("token")
    .split(".")[1])
);
pm.test("Is admin", () => {
  pm.expect(payload.role)
    .to.eql("admin");
});

Test security: without a token it should return 401, with an invalid token 403. You can decode the JWT (part 2 in base64) and validate claims like role or expiration.

# Windows:
# 1. Download at postman.com/downloads
# 2. Run the installer (.exe)
# 3. Opens automatically after installing

# macOS:
brew install --cask postman

# Linux (Ubuntu/Debian via snap):
sudo snap install postman

# Check version:
# Help > About (in the top menu)

Download at postman.com/downloads (Windows) or use brew (macOS) and snap (Linux). The app is free with an optional account. Updates are automatic by default.

# Sidebar (left):
#   Collections | Environments
#   History | Mocks | Monitors

# Request tab:
#   Params | Auth | Headers | Body
#   Pre-request | Tests | Settings

# Response panel (bottom):
#   Body | Cookies | Headers | Tests

# Bottom bar:
#   Console (Ctrl+Alt+C)
#   shows all real requests

The sidebar has Collections, Environments and History. Each request has tabs for Params, Auth, Headers, Body and Tests. The Console (Ctrl+Alt+C) shows the real traffic — essential for debugging.

# Postman Web (browser):
#   web.postman.co
#   - No installation
#   - Needs the Postman Desktop Agent
#     for real requests (CORS)

# Postman Desktop:
#   - Full access to the local network
#   - Native Interceptor and proxy
#   - Better performance

# Both sync via the account

The web version runs in the browser but needs the Desktop Agent to work around CORS. The desktop version has full access to the local network. Everything syncs through the Postman account.

Ctrl + N          // new request (tab)
Ctrl + Shift + N  // new collection
Ctrl + S          // save request
Ctrl + Enter      // send request
Ctrl + Alt + C    // open Console
Ctrl + K          // global search
Ctrl + D          // duplicate tab
Ctrl + Shift + F  // format JSON body
Ctrl + [ / ]      // previous/next tab
Ctrl + Alt + N    // new window

Essential shortcuts: Ctrl+Enter sends, Ctrl+S saves, Ctrl+K searches everything, Ctrl+Shift+F formats JSON. They speed up daily work a lot.

# Create an account:
#   postman.com > Sign Up (free)

# Workspaces (organization):
#   My Workspace    → personal
#   Team Workspace  → shared
#   Public          → visible to everyone

# Create a workspace:
#   Workspaces > Create Workspace
#   > invite members by email

# Automatic sync:
#   Collections, environments and tests
#   are available everywhere

The free account allows personal and team workspaces. Workspaces organize collections per project/team. Everything stays synced in the cloud automatically.

# Install Newman (requires Node.js):
npm install -g newman

# Check:
newman --version

# Run an exported collection:
newman run my-collection.json

# With an environment:
newman run collection.json \
  -e environment.json

# Newman is Postman's command-line
# runner — it allows running
# collections in CI/CD

Newman is Postman's official CLI (install via npm). It allows running collections in the terminal and in CI/CD pipelines. Export the collection the JSON before running.

# 1. "+" button or Ctrl+N (new tab)
# 2. Method: GET
# 3. URL: https://jsonplaceholder.typicode.com/users
# 4. "Send" button (or Ctrl+Enter)

# The response appears below:
#   Status: 200 OK
#   Time: 145 ms
#   Body: formatted JSON

# Save:
#   Ctrl+S > choose a collection
#   (or create a new one)

Create a tab with Ctrl+N, pick the GET method, paste the URL and click Send. The response shows status, time and body. Save with Ctrl+S into a collection.

# Settings: gear icon (corner)

# General:
#   Request timeout: 0 (no limit)
#   SSL verification: on/off
#   (off for self-signed certificates)

# Proxy:
#   Settings > Proxy
#   Use system proxy: on
#   Or manual: host + port

# Client certificates:
#   Settings > Certificates
#   > Add (.pem/.pfx file)

In Settings you configure timeout, SSL verification (turn it off for self-signed certificates) and proxy. Client certificates are added in Certificates.

# Export the collection (JSON v2.1)
# and run:

newman run api-users.json

# Report in the terminal:
#   ✓ Status is 200
#   ✗ Correct name (failed)
#   iterations, time, total

# HTML report:
npm install -g newman-reporter-html
newman run api-users.json \
  -r cli,html

newman run executes the exported collection and shows passed/failed tests in the terminal. Install newman-reporter-html for shareable HTML reports. The base for automation.

// Collection > "..." > Monitor

// Configuration:
//   Name: "API Prod - 5min"
//   Environment: Prod
//   Frequency: every 5 minutes
//   Notify: email on failure

// Runs the collection (with
// tests) periodically in the cloud

// History in:
//   Monitors > uptime chart
//   and response times

Monitors run the collection in the cloud at regular intervals (e.g. 5 min) and notify by email on failures. They provide uptime history and response times — continuous monitoring without infrastructure.

# With an exported environment:
newman run col.json -e dev.json

# With a data file:
newman run col.json -d data.csv

# Multiple iterations:
newman run col.json -n 5

# Timeout and options:
newman run col.json \
  --timeout-request 5000 \
  --delay-request 200 \
  --bail   # stop at the 1st failure

Combine flags: -e (environment), -d (CSV/JSON data), -n (iterations), --delay-request (pause between requests) and --bail (stop at the first failure). It mirrors the Runner options.

// 1. Install the Chrome extension:
//    "Postman Interceptor"

// 2. In Postman desktop:
//    satellite icon (bottom left corner)
//    > Interceptor > Connect

// 3. Browse in the browser — all
//    the requests are captured
//    into Postman

// Filter by domain:
//    Domain: api.example.com

// Import real requests for
// debugging or building collections

The Interceptor (Chrome extension) captures real requests from the browser and sends them to Postman. Filter by domain. Perfect for debugging production APIs and building collections from real traffic.

# .github/workflows/api-tests.yml
name: API Tests
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm install -g newman
      - run: >
          newman run tests/api.json
          -e tests/env-ci.json

Integrate API tests in GitHub Actions: install newman and run the collection on every push. The build fails if any test fails. It works the same in GitLab CI, Jenkins or any CI with Node.

// Postman can act the a proxy:
// Settings > Proxy > port 5555

// Configure the browser/app:
//   proxy: localhost:5555

// All the traffic goes through
// Postman and stays in the History

// Capture requests from mobile
// apps (same WiFi network):
//   use the machine's IP
//   the the proxy on the phone

Postman can work the a proxy (Settings > Proxy): all the traffic going through it stays in the History. Useful to capture requests from mobile apps on the same network — use the machine's IP the the proxy.

// 1. Save examples on the requests:
//    Send > "Save the example"
//    (expected status + body)

// 2. Collection > "..." > Mock

// Generated URL:
// https://abc123.mock.pstmn.io

// Replace the base_url:
// {{mock_url}}/users
// returns the saved examples

// The frontend works without a backend!

Mock Servers simulate the API without a backend. Save examples (expected responses) on the requests and create the mock — the generated URL returns those examples. It allows developing the frontend in parallel.

// API Builder (sidebar "APIs"):
//   Define the OpenAPI schema
//   > generates an automatic collection
//   > validates requests vs schema

// Comments:
//   select text > comment
//   (like code review)

// Collection pull requests:
//   Fork > change > Create PR
//   > review > Merge

// Roles: Viewer | Editor | Admin
// per workspace and collection

The API Builder starts from the OpenAPI schema and generates collections validating requests against the schema. Comments, forks and pull requests bring a code review flow to APIs. Roles control permissions.