Cheatsheet Postman

GET     // obtener datos (sin body)
POST    // crear un recurso
PUT     // reemplazar el recurso entero
PATCH   // actualización parcial
DELETE  // eliminar un recurso
HEAD    // solo headers (sin body)
OPTIONS // métodos permitidos

// Seleccionar en el dropdown a la
// izquierda de la URL. Ejemplo:
// POST https://api.example.com/users

Elige el método en el dropdown junto a la URL. GET lee, POST crea, PUT reemplaza, PATCH actualiza parcialmente, DELETE elimina. HEAD y OPTIONS sirven para inspección.

// Pestaña "Params" — pares key/value:
//   page = 1
//   limit = 10
//   q = postman

// URL generada automáticamente:
// https://api.example.com/users
//   ?page=1&limit=10&q=postman

// Desactivar un param: desmarcar
// la checkbox (no borrar)

// Postman hace encode automático
// de espacios y caracteres especiales

Los parámetros de query se definen en la pestaña Params — la URL se construye automáticamente. Desactiva con la checkbox en vez de borrar. Postman hace URL encoding automático de caracteres especiales.

// Pestaña "Headers" — pares key/value:
Content-Type: application/json
Accept: application/json
Authorization: Bearer {{token}}
X-API-Key: {{api_key}}

// Los headers generados automáticamente
// aparecen en gris (ocultos)
// en "hidden headers"

// Desactivar un header:
//   desmarcar la checkbox
// Bulk edit: botón "bulk edit"
//   para pegar varias líneas

Los headers se definen en la pestaña Headers como pares clave/valor. Content-Type indica el formato del body. Los headers automáticos (como User-Agent) quedan ocultos. Usa bulk edit para pegar varios a la vez.

// URL con variable de ruta:
// https://api.example.com/users/:id

// Al escribir ":id", aparece
// automáticamente en la pestaña Params
// (sección "Path Variables"):
//   id = 42

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

// Múltiples:
// /users/:userId/posts/:postId

Las path variables usan :nombre en la URL (ej.: /users/:id). Postman las añade automáticamente a la pestaña Params en la sección Path Variables. Más legible que query params para identificadores.

// Pestaña Body > raw > JSON

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

// Ctrl+Shift+F formatea el JSON
// Postman valida la sintaxis y
// avisa si hay errores

// El header Content-Type se
// añade automáticamente

En la pestaña Body elige raw + JSON. Formatea con Ctrl+Shift+F — Postman valida la sintaxis. El header Content-Type: application/json se añade automáticamente.

// Tras Send, el panel muestra:
//   Status: 200 OK (verde)
//   4xx naranja | 5xx rojo
//   Time: 145 ms
//   Size: 2.3 KB

// Pestañas de la respuesta:
//   Body    → Pretty | Raw | Preview
//   Cookies → cookies recibidas
//   Headers → headers de la respuesta
//   Tests   → resultados de los tests

// "Save as example" guarda la
// respuesta como ejemplo (mocks)

La respuesta muestra status (verde 2xx, naranja 4xx, rojo 5xx), tiempo y tamaño. Pestañas: Body (Pretty/Raw/Preview), Cookies, Headers y Tests. Save as example guarda respuestas para mocks.

// Body > form-data (multipart):
//   name: Ana
//   file: [Select Files]
//   (cambia el tipo a "File"
//    en el dropdown de la fila)

// Body > x-www-form-urlencoded:
//   name=Ana&age=30
//   (formato clásico de formularios)

// Body > binary:
//   enviar un archivo puro
//   (imagen, PDF, etc.)

form-data envía multipart (con archivos — cambia la fila al tipo File). x-www-form-urlencoded es el formato clásico de formularios. binary envía archivos puros (imágenes, PDFs).

// Enlace "Cookies" (debajo de Send)
// muestra el cookie jar por dominio

// Postman guarda cookies entre
// requests automáticamente
// (como un navegador)

// Ejemplo: un login guarda la
// cookie de sesión, y los requests
// siguientes la envían solos

// Borrar cookies:
//   Cookies > dominio > X
//   (útil para probar logout)

Postman gestiona cookies automáticamente como un navegador — un login guarda la cookie de sesión y los requests siguientes la envían. Gestiona el cookie jar en el enlace Cookies (borra para probar escenarios sin sesión).

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

// Nombre: "Users API"
// Descripción (opcional, markdown)

// Guardar requests en la collection:
//   Ctrl+S en el request abierto
//   o arrastrar la pestaña

// Una collection agrupa todos
// los requests de una API/proyecto

Una collection agrupa todos los requests de un proyecto. Créala con Ctrl+Shift+N y guarda requests con Ctrl+S o arrastrando pestañas. La descripción soporta markdown.

// Flows (sidebar) > Create Flow

// Bloques disponibles:
//   Request  → llama a un request
//   Delay    → espera X segundos
//   Condition → if/else por valor
//   Set Variable

// Conecta bloques con flechas para
// crear workflows visuales:
//   Login > condición (¿200?)
//   > Get datos > Notificar

// Ejecutar manual o programar

Los Flows crean workflows visuales conectando bloques: Request, Delay, Condition, Set Variable. Ideales para secuencias con lógica (login → condición → acción) sin escribir código.

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

// Estructura recomendada:
// Users API/
//   Auth/
//     Login, Logout, Refresh
//   Users/
//     List, Create, Update
//   Admin/
//     Statistics

// Arrastra para mover requests
// entre carpetas. Las carpetas pueden
// tener auth, tests y variables
// propios (heredados por los hijos)

Organiza con carpetas por recurso (Auth, Users, Admin). Las carpetas pueden tener auth, tests y variables propios que los requests hijos heredan. Arrastra para reorganizar.

// Compartir:
//   Collection > Share
//   > Vía workspace (equipo)
//   > Vía enlace público (view-only)

// Versionar con Git:
//   Settings > Connected to Git
//   (GitHub, GitLab, Bitbucket)
//   Cada cambio = commit

// Fork:
//   Fork Collection > cambiar
//   > Merge de vuelta (como Git)

Comparte vía workspace (equipo) o enlace público (view-only). Conecta a Git para versionar cambios como commits. Fork + merge funcionan como en Git — cambia sin afectar al original.

// Import (botón Import):
//   - Archivo JSON (Postman v2.1)
//   - OpenAPI / Swagger (URL o archivo)
//   - cURL (pegar el comando)
//   - HAR, WSDL, RAML

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

// cURL a Postman:
//   Import > Raw text > pegar:
//   curl -X GET https://api...

Importa desde OpenAPI/Swagger, cURL, HAR y JSON. Exporta en Collection v2.1 (JSON) para compartir o versionar. Pegar un comando cURL lo convierte en request automáticamente.

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

// Genera documentación automática:
//   - Todos los requests
//   - Parámetros y bodies
//   - Ejemplos de respuesta
//   - Scripts de test

// Publicar:
//   Docs > Publish (enlace público)
//   postman.com/docs/...

// Mejora con descripciones en los
// requests y "examples" guardados

Postman genera documentación automática a partir de la collection (requests, params, ejemplos). Publica con un clic en Docs > Publish. Las descripciones y los examples guardados enriquecen la documentación.

// Collection > botón "Run"
// (o Runner en la sidebar)

// Configuración:
//   Environment: Dev
//   Iterations: 3 (repeticiones)
//   Delay: 200 ms entre requests
//   Data: archivo CSV/JSON

// Ejecuta todos los requests en
// secuencia y muestra un informe
// con tests pasados/fallidos

El Runner ejecuta toda la collection en secuencia con tests. Configura iterations (repeticiones), delay entre requests y archivo de data (CSV/JSON). Muestra un informe con tests pasados/fallidos.

// Collection > Edit > Variables

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

// Usar en cualquier request:
// {{base_url}}/{{version}}/users

// Todos los requests de la collection
// comparten estas variables

// Cambiar aquí cambia en todas partes

Las variables de collection se definen en Edit > Variables y quedan disponibles en todos los requests vía {{nombre}}. Perfectas para base_url — cambia en un sitio y se actualiza todo.

// Environments (sidebar) > "+"

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

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

// Activar: dropdown en la esquina
// superior derecha (ojo = preview)

Crea un entorno por contexto (Dev, Staging, Prod) con sus variables. Actívalo en el dropdown de la esquina superior derecha. El mismo request funciona en todos los entornos sin cambiar nada.

// Pestaña "Pre-request" — corre
// ANTES de cada request:

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

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

// Útil para: tokens, hashes,
// datos dinámicos, limpieza

El Pre-request Script corre antes del request — ideal para generar timestamps, firmas HMAC o preparar datos. Usa pm.environment.set() para guardar valores usados en el request.

// Sintaxis: {{variable_name}}

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

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

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

// Las variables activas aparecen en
// naranja; las inexistentes en rojo

Las variables usan la sintaxis {{nombre}} en cualquier campo (URL, headers, body). Aparecen en naranja cuando se resuelven y en rojo cuando no existen. Pasa el ratón para ver el valor actual.

// Entorno > Edit > Pre-request
// y > Tests (corren en TODOS los
// requests de ese entorno)

// Ejemplo (Pre-request del env):
// garantizar que hay token antes
// de cualquier request:
if (!pm.environment.get("token")) {
  console.log("⚠️ ¡Sin token!");
}

// Evita repetir scripts iguales
// en cada request de la collection

Los entornos también tienen Pre-request y Tests que corren en todos los requests de ese entorno. Perfecto para validaciones globales (ej.: garantizar que existe token) sin repetir código en cada request.

// Orden de resolución (mayor gana):
// 1. Data       (archivo del Runner)
// 2. Local      (pm.variables.set)
// 3. Environment (entorno activo)
// 4. Collection (variables de la col.)
// 5. Global     (visibles en todo)

// Ejemplo: si "base_url" existe
// en el entorno Y en la collection,
// gana la del entorno

// Debug: la Console (Ctrl+Alt+C)
// muestra qué valor se usó

Precedencia (mayor gana): Data > Local > Environment > Collection > Global. Si la misma variable existe en varios scopes, gana el más específico. La Console muestra el valor usado.

// Dropdown en la esquina superior derecha
// > seleccionar: Dev | Staging | Prod

// Alternancia instantánea:
//   mismo request, URLs diferentes

// "No Environment" = solo variables
// de collection/globales activas

// Icono del ojo (preview):
//   muestra los valores del entorno
//   sin activarlo

// Duplicar entorno:
//   "..." > Duplicate (base p/ Prod)

Alterna entornos en el dropdown de la esquina superior derecha — el mismo request pasa a apuntar a otra URL. El icono del ojo muestra valores sin activar. Duplica un entorno para crear variantes rápidamente.

// Placeholders automáticos:
{{$guid}}          // UUID v4
{{$timestamp}}     // epoch seconds
{{$randomInt}}     // 0-1000
{{$randomEmail}}   // email aleatorio
{{$randomFullName}}
{{$randomUUID}}
{{$randomPassword}}
{{$randomLoremWord}}

// Útiles en bodies de test:
// { "email": "{{$randomEmail}}" }

Las variables dinámicas ({{$guid}}, {{$timestamp}}, {{$randomEmail}}...) generan valores automáticos en cada ejecución. Ideales para crear datos de test únicos sin scripts.

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

// Leer (respeta el scope):
const url = pm.variables.get("base_url");

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

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

// pm.variables.get() búsqueda en
// todos los scopes automáticamente

En scripts: pm.variables.get() lee respetando el scope; pm.environment.set(), pm.collectionVariables.set() y pm.globals.set() guardan en scopes específicos. unset() borra.

// Pestaña "Tests" — corre DESPUÉS
// de recibir la respuesta:

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

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

// Los resultados aparecen en la
// pestaña "Tests" del panel de respuesta

Los tests se escriben en la pestaña Tests con pm.test() — cada uno aparece como pasado/fallido en el panel de respuesta. Usan la sintaxis Chai (expect/should). Corren tras cada respuesta.

// Panel derecho de la pestaña Tests:
// "Snippets" — bloques listos

// Más usados:
// - Status code: Code is 200
// - Response body: Contains string
// - Response body: JSON value check
// - Response time < 200ms
// - Status: Successful POST

// Haz clic en un snippet y el código
// se inserta — ajusta los valores

// La búsqueda arriba filtra la lista

Los snippets (panel derecho de la pestaña Tests) son bloques de test listos para usar: status 200, JSON value check, response time, etc. Haz clic para insertar y ajusta los valores — ideal para empezar rápido.

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

// Status entre varios:
pm.test("Éxito", () => {
  pm.expect(pm.response.code)
    .to.be.oneOf([200, 201]);
});

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

// Tiempo de respuesta:
pm.test("Rápido", () => {
  pm.expect(pm.response.responseTime)
    .to.be.below(500);
});

Asserts comunes: to.have.status() verifica el código, oneOf([200, 201]) acepta varios, to.have.header() confirma headers y responseTime mide rendimiento en ms.

// Valida la ESTRUCTURA de la respuesta
// con tv4 (incluido en Postman):

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

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

La validación de schema confirma la estructura (tipos, campos obligatorios) en vez de valores exactos. Usa tv4 (incluido en Postman) con JSON Schema. Detecta breaking changes en la API.

const json = pm.response.json();

pm.test("Nombre correcto", () => {
  pm.expect(json.name).to.eql("Ana");
});

pm.test("Tiene id numérico", () => {
  pm.expect(json.id).to.be.a("number");
});

pm.test("Lista no vacía", () => {
  pm.expect(json.items)
    .to.have.lengthOf.above(0);
});

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

Convierte la respuesta con pm.response.json() y valida campos: to.eql() compara valores, to.be.a("number") verifica tipos, lengthOf.above(0) confirma arrays no vacíos, to.have.property() verifica existencia.

// Archivo data.csv:
// name,email
// Ana,ana@mail.com
// Ray,rui@mail.com

// En el Runner: Data > seleccionar CSV

// En el body del request:
// { "name": "{{name}}",
//   "email": "{{email}}" }

// Cada iteración usa una línea
// del archivo (2 líneas = 2 runs)

// pm.iterationData.get("name")
// lee el valor actual en scripts

Data-driven testing: crea un CSV/JSON con una línea por escenario y selecciónalo en el Runner. Cada iteración usa valores diferentes vía {{columna}}. En scripts, lee con pm.iterationData.get().

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

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

// El Runner ejecuta en secuencia
// y el token fluye automáticamente

Patrón esencial: en el test del login, guarda el token con pm.environment.set(). Los requests siguientes usan {{token}} en el header. En el Runner, los datos fluyen automáticamente entre requests.

// Presenta la respuesta como
// HTML personalizado:

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

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

// Ver en: Body > Visualize

El Visualizer renderiza la respuesta como HTML custom con templates Handlebars. Define el template con pm.visualizer.set() en Tests y ve el resultado en la pestaña Visualize. Genial para informes legibles.

// Pestaña "Authorization" del request

// Type: "No Auth"
//   (sin autenticación)

// Type: "Inherit auth from parent"
//   usa la auth de la carpeta o
//   collection (por defecto)

// Definir auth en la collection:
//   Collection > Authorization
//   > Bearer Token {{token}}
//   ¡Todos los requests la heredan!

// Cambiar el token en un solo lugar

No Auth envía sin credenciales. Inherit auth from parent (por defecto) usa la auth de la carpeta o collection. Definir auth a nivel de collection la aplica a todos los requests — cambia el token en un solo lugar.

// 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" abre
// el navegador para login y obtiene
// el token automáticamente

OAuth 2.0 soporta varios grant types (Authorization Code, Client Credentials, etc.). Rellena Auth URL, Token URL, Client ID/Secret y haz clic en Get New Access Token — Postman gestiona todo el flujo.

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

// Header generado automáticamente:
// Authorization: Bearer eyJhbG...

// Flujo típico:
// 1. Request de login (POST)
// 2. El test guarda:
//    pm.environment.set("token",
//      pm.response.json().token)
// 3. Los demás requests usan
//    Bearer {{token}}

Bearer Token es el método más común en APIs modernas (JWT). Pon {{token}} en el campo y el header Authorization: Bearer ... se genera automáticamente. Combina con el test del login que guarda el token.

// OAuth 1.0 (firma, sin token):
//   Consumer Key / Secret
//   Token / Token Secret
//   Signature Method: HMAC-SHA1
//   (usado por APIs antiguas,
//    ej.: Twitter v1)

// Digest Auth:
//   Username / Password
//   (negocia challenge-response
//    con el servidor — más seguro
//    que Basic, sin enviar la pass)

// Ambos generan headers automáticos

OAuth 1.0 firma requests con HMAC-SHA1 (APIs antiguas). Digest Auth usa challenge-response sin enviar la contraseña en claro — más seguro que Basic. Postman genera los headers complejos automáticamente.

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

// Header generado:
// Authorization: Basic dXNlcjpwYXNz
// (base64 de "user:pass")

// Atención: base64 NO es
// cifrado — usar siempre
// sobre HTTPS en producción

Basic Auth envía usuario y contraseña codificados en base64 en el header Authorization. Simple pero inseguro sin HTTPS — base64 es codificación, no cifrado.

// 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);
  });
}

Automatización total: en el Pre-request de la collection, pm.sendRequest() hace login y guarda el token si no existe. Todos los requests quedan autenticados automáticamente sin intervención manual.

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

// Header generado:
// X-API-KEY: abc123xyz

// O en query (menos seguro):
// ?X-API-KEY=abc123xyz

// Guarda la clave en una variable
// de entorno (nunca hardcoded)

API Key envía la clave en un header custom (ej.: X-API-KEY) o en query params. Elige Header (más seguro). Guarda siempre el valor en una variable de entorno, nunca hardcoded.

// Probar endpoints protegidos:

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

// Con token inválido:
pm.test("Token inválido = 403", () => {
  pm.response.to.have.status(403);
});

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

Prueba la seguridad: sin token debe devolver 401, con token inválido 403. Puedes decodificar el JWT (parte 2 en base64) y validar claims como role o expiración.

# Windows:
# 1. Descarga en postman.com/downloads
# 2. Ejecutar el instalador (.exe)
# 3. Se abre automáticamente tras instalar

# macOS:
brew install --cask postman

# Linux (Ubuntu/Debian vía snap):
sudo snap install postman

# Verificar versión:
# Help > About (en el menú superior)

Descarga en postman.com/downloads (Windows) o usa brew (macOS) y snap (Linux). La app es gratuita con cuenta opcional. Las actualizaciones son automáticas por defecto.

# Barra lateral (izquierda):
#   Collections | Environments
#   History | Mocks | Monitors

# Pestaña del request:
#   Params | Auth | Headers | Body
#   Pre-request | Tests | Settings

# Panel de respuesta (abajo):
#   Body | Cookies | Headers | Tests

# Barra inferior:
#   Console (Ctrl+Alt+C)
#   muestra todos los requests reales

La sidebar tiene Collections, Environments e History. Cada request tiene pestañas para Params, Auth, Headers, Body y Tests. La Console (Ctrl+Alt+C) muestra el tráfico real — esencial para debug.

# Postman Web (navegador):
#   web.postman.co
#   - Sin instalación
#   - Necesita el Postman Desktop Agent
#     para requests reales (CORS)

# Postman Desktop:
#   - Acceso total a la red local
#   - Interceptor y proxy nativos
#   - Mejor rendimiento

# Ambos sincronizan vía cuenta

La versión web corre en el navegador pero necesita el Desktop Agent para sortear CORS. La versión desktop tiene acceso total a la red local. Todo se sincroniza con la cuenta de Postman.

Ctrl + N          // nuevo request (pestaña)
Ctrl + Shift + N  // nueva collection
Ctrl + S          // guardar request
Ctrl + Enter      // enviar request
Ctrl + Alt + C    // abrir la Console
Ctrl + K          // búsqueda global
Ctrl + D          // duplicar pestaña
Ctrl + Shift + F  // formatear body JSON
Ctrl + [ / ]      // pestaña anterior/siguiente
Ctrl + Alt + N    // nueva ventana

Atajos esenciales: Ctrl+Enter envía, Ctrl+S guarda, Ctrl+K búsqueda todo, Ctrl+Shift+F formatea JSON. Aceleran mucho el trabajo diario.

# Crear cuenta:
#   postman.com > Sign Up (gratis)

# Workspaces (organización):
#   My Workspace    → personal
#   Team Workspace  → compartido
#   Public          → visible para todos

# Crear workspace:
#   Workspaces > Create Workspace
#   > invitar miembros por email

# Sync automático:
#   Collections, entornos y tests
#   quedan disponibles en todas partes

La cuenta gratis permite workspaces personales y de equipo. Los Workspaces organizan collections por proyecto/equipo. Todo queda sincronizado en la nube automáticamente.

# Instalar Newman (requiere Node.js):
npm install -g newman

# Verificar:
newman --version

# Ejecutar una collection exportada:
newman run my-collection.json

# Con entorno:
newman run collection.json \
  -e environment.json

# Newman es el runner de línea de
# comandos de Postman — permite
# ejecutar collections en CI/CD

Newman es el CLI oficial de Postman (instala vía npm). Permite ejecutar collections en la terminal y en pipelines de CI/CD. Exporta la collection en JSON antes de ejecutar.

# 1. Botón "+" o Ctrl+N (nueva pestaña)
# 2. Método: GET
# 3. URL: https://jsonplaceholder.typicode.com/users
# 4. Botón "Send" (o Ctrl+Enter)

# La respuesta aparece abajo:
#   Status: 200 OK
#   Time: 145 ms
#   Body: JSON formateado

# Guardar:
#   Ctrl+S > elegir collection
#   (o crear una nueva)

Crea una pestaña con Ctrl+N, elige el método GET, pega la URL y haz clic en Send. La respuesta muestra status, tiempo y body. Guarda con Ctrl+S en una collection.

# Settings: icono de engranaje (esquina)

# General:
#   Request timeout: 0 (sin límite)
#   SSL verification: on/off
#   (off para certificados self-signed)

# Proxy:
#   Settings > Proxy
#   Usar proxy del sistema: on
#   O manual: host + puerto

# Certificados cliente:
#   Settings > Certificates
#   > Add (archivo .pem/.pfx)

En Settings configuras timeout, verificación SSL (desactívala para certificados self-signed) y proxy. Los certificados cliente se añaden en Certificates.

# Exportar la collection (JSON v2.1)
# y ejecutar:

newman run api-users.json

# Informe en la terminal:
#   ✓ Status es 200
#   ✗ Nombre correcto (falló)
#   iterations, tiempo, total

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

newman run ejecuta la collection exportada y muestra tests pasados/fallidos en la terminal. Instala newman-reporter-html para informes HTML compartibles. La base para la automatización.

// Collection > "..." > Monitor

// Configuración:
//   Nombre: "API Prod - 5min"
//   Environment: Prod
//   Frequency: every 5 minutes
//   Notify: email en fallo

// Ejecuta la collection (con
// tests) periódicamente en la nube

// Historial en:
//   Monitors > gráfico de uptime
//   y tiempos de respuesta

Los Monitors ejecutan la collection en la nube a intervalos regulares (ej.: 5 min) y notifican por email en fallos. Dan historial de uptime y tiempos de respuesta — monitorización continua sin infraestructura.

# Con entorno exportado:
newman run col.json -e dev.json

# Con archivo de datos:
newman run col.json -d data.csv

# Múltiples iteraciones:
newman run col.json -n 5

# Timeout y opciones:
newman run col.json \
  --timeout-request 5000 \
  --delay-request 200 \
  --bail   # parar en el 1er fallo

Combina flags: -e (entorno), -d (datos CSV/JSON), -n (iteraciones), --delay-request (pausa entre peticiones) y --bail (para en el primer fallo). Refleja las opciones del Runner.

// 1. Instalar la extensión de Chrome:
//    "Postman Interceptor"

// 2. En Postman desktop:
//    icono satélite (esquina inf. izq.)
//    > Interceptor > Connect

// 3. Navegar en el navegador — todos
//    los requests se capturan
//    hacia Postman

// Filtrar por dominio:
//    Domain: api.example.com

// Importar requests reales para
// debug o crear collections

El Interceptor (extensión de Chrome) captura requests reales del navegador y los envía a Postman. Filtra por dominio. Perfecto para debug de APIs en producción y crear collections a partir de tráfico real.

# .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

Integra tests de API en GitHub Actions: instala newman y ejecuta la collection en cada push. El build falla si algún test falla. Funciona igual en GitLab CI, Jenkins o cualquier CI con Node.

// Postman puede actuar como proxy:
// Settings > Proxy > puerto 5555

// Configurar el navegador/app:
//   proxy: localhost:5555

// Todo el tráfico pasa por
// Postman y queda en el History

// Capturar requests de apps
// móviles (misma red WiFi):
//   usar la IP de la máquina
//   como proxy en el móvil

Postman puede funcionar como proxy (Settings > Proxy): todo el tráfico que pasa por él queda en el History. Sirve para capturar requests de apps móviles en la misma red — usa la IP de la máquina como proxy.

// 1. Guardar ejemplos en los requests:
//    Send > "Save as example"
//    (status + body esperados)

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

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

// Sustituye la base_url:
// {{mock_url}}/users
// devuelve los ejemplos guardados

// ¡El frontend trabaja sin backend!

Los Mock Servers simulan la API sin backend. Guarda examples (respuestas esperadas) en los requests y crea el mock — la URL generada devuelve esos ejemplos. Permite desarrollar el frontend en paralelo.

// API Builder (sidebar "APIs"):
//   Define el schema OpenAPI
//   > genera collection automática
//   > valida requests vs schema

// Comentarios:
//   seleccionar texto > comentar
//   (como code review)

// Pull requests de collections:
//   Fork > cambiar > Create PR
//   > review > Merge

// Roles: Viewer | Editor | Admin
// por workspace y collection

El API Builder parte del schema OpenAPI y genera collections validando requests contra el schema. Comentarios, forks y pull requests traen el flujo de code review a las APIs. Los roles controlan permisos.