Cheatsheet Postman

GET     // obter dados (sem body)
POST    // criar recurso
PUT     // substituir recurso inteiro
PATCH   // atualização parcial
DELETE  // remover recurso
HEAD    // só headers (sem body)
OPTIONS // métodos permitidos

// Selecionar no dropdown à
// esquerda da URL. Exemplo:
// POST https://api.exemplo.com/users

Escolhe o método no dropdown junto à URL. GET lê, POST cria, PUT substitui, PATCH atualiza parcialmente, DELETE remove. HEAD e OPTIONS servem para inspeção.

// Tab "Params" — pares key/value:
//   page = 1
//   limit = 10
//   q = postman

// URL gerada automaticamente:
// https://api.exemplo.com/users
//   ?page=1&limit=10&q=postman

// Desativar param: desmarcar
// a checkbox (não apagar)

// Postman faz encode automático
// de espaços e caracteres especiais

Parâmetros de query definem-se na tab Params — a URL é construída automaticamente. Desativa com a checkbox em vez de apagar. O Postman faz URL encoding automático de caracteres especiais.

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

// Headers gerados automaticamente
// aparecem a cinzento (ocultos)
// em "hidden headers"

// Desativar um header:
//   desmarcar a checkbox
// Bulk edit: botão "bulk edit"
//   para colar várias linhas

Headers definem-se na tab Headers como pares chave/valor. Content-Type indica o formato do body. Headers automáticos (como User-Agent) ficam ocultos. Usa bulk edit para colar vários de uma vez.

// URL com variável de caminho:
// https://api.exemplo.com/users/:id

// Ao escrever ":id", aparece
// automaticamente na tab Params
// (secção "Path Variables"):
//   id = 42

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

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

Path variables usam :nome na URL (ex.: /users/:id). O Postman adiciona-as automaticamente à tab Params na secção Path Variables. Mais legível que query params para identificadores.

// Tab Body > raw > JSON

{
  "nome": "Ana",
  "idade": 30,
  "ativa": true,
  "tags": ["dev", "api"]
}

// Ctrl+Shift+F formata o JSON
// Postman valida a sintaxe e
// avisa se houver erros

// O header Content-Type é
// adicionado automaticamente

Na tab Body escolhe raw + JSON. Formata com Ctrl+Shift+F — o Postman valida a sintaxe. O header Content-Type: application/json é adicionado automaticamente.

// Após Send, o painel mostra:
//   Status: 200 OK (verde)
//   4xx laranja | 5xx vermelho
//   Time: 145 ms
//   Size: 2.3 KB

// Tabs da resposta:
//   Body    → Pretty | Raw | Preview
//   Cookies → cookies recebidos
//   Headers → headers da resposta
//   Tests   → resultados dos testes

// "Save as example" guarda a
// resposta como exemplo (mocks)

A resposta mostra status (verde 2xx, laranja 4xx, vermelho 5xx), tempo e tamanho. Tabs: Body (Pretty/Raw/Preview), Cookies, Headers e Tests. Save as example guarda respostas para mocks.

// Body > form-data (multipart):
//   nome: Ana
//   ficheiro: [Select Files]
//   (muda o tipo para "File"
//    no dropdown da linha)

// Body > x-www-form-urlencoded:
//   nome=Ana&idade=30
//   (formato clássico de forms)

// Body > binary:
//   enviar ficheiro puro
//   (imagem, PDF, etc.)

form-data envia multipart (com ficheiros — muda a linha para tipo File). x-www-form-urlencoded é o formato clássico de formulários. binary envia ficheiros puros (imagens, PDFs).

// Link "Cookies" (abaixo do Send)
// mostra o cookie jar por domínio

// Postman guarda cookies entre
// requests automaticamente
// (como um browser)

// Exemplo: login guarda
// session cookie, e os requests
// seguintes enviam-no sozinho

// Apagar cookies:
//   Cookies > domínio > X
//   (útil para testar logout)

O Postman gere cookies automaticamente como um browser — um login guarda o cookie de sessão e os requests seguintes enviam-no. Gere o cookie jar no link Cookies (apaga para testar cenários sem sessão).

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

// Nome: "API Utilizadores"
// Descrição (opcional, markdown)

// Guardar requests na collection:
//   Ctrl+S no request aberto
//   ou arrastar o tab

// Uma collection agrupa todos
// os requests de uma API/projeto

Uma collection agrupa todos os requests de um projeto. Cria com Ctrl+Shift+N e guarda requests com Ctrl+S ou arrastando tabs. A descrição suporta markdown.

// Flows (sidebar) > Create Flow

// Blocos disponíveis:
//   Request  → chama um request
//   Delay    → espera X segundos
//   Condition → if/else por valor
//   Set Variable

// Liga blocos com setas para
// criar workflows visuais:
//   Login > condição (200?)
//   > Get dados > Notificar

// Executar manual ou agendar

Flows criam workflows visuais ligando blocos: Request, Delay, Condition, Set Variable. Ideais para sequências com lógica (login → condição → ação) sem escrever código.

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

// Estrutura recomendada:
// API Utilizadores/
//   Auth/
//     Login, Logout, Refresh
//   Utilizadores/
//     Listar, Criar, Atualizar
//   Admin/
//     Estatísticas

// Arrastar para mover requests
// entre pastas. Pastas podem
// ter auth, testes e variáveis
// próprios (herdados pelos filhos)

Organiza com pastas por recurso (Auth, Utilizadores, Admin). Pastas podem ter auth, tests e variables próprios que os requests filhos herdam. Arrasta para reorganizar.

// Partilhar:
//   Collection > Share
//   > Via workspace (equipa)
//   > Via link público (view-only)

// Versionar com Git:
//   Settings > Connected to Git
//   (GitHub, GitLab, Bitbucket)
//   Cada alteração = commit

// Fork:
//   Fork Collection > alterar
//   > Merge de volta (como Git)

Partilha via workspace (equipa) ou link público (view-only). Liga ao Git para versionar alterações como commits. Fork + merge funcionam como no Git — altera sem afetar o original.

// Import (botão Import):
//   - Ficheiro JSON (Postman v2.1)
//   - OpenAPI / Swagger (URL ou file)
//   - cURL (colar o comando)
//   - HAR, WSDL, RAML

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

// cURL para Postman:
//   Import > Raw text > colar:
//   curl -X GET https://api...

Importa de OpenAPI/Swagger, cURL, HAR e JSON. Exporta em Collection v2.1 (JSON) para partilhar ou versionar. Colar um comando cURL converte-o em request automaticamente.

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

// Gera documentação automática:
//   - Todos os requests
//   - Parâmetros e bodies
//   - Exemplos de resposta
//   - Scripts de teste

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

// Melhora com descrições nos
// requests e "examples" salvos

O Postman gera documentação automática a partir da collection (requests, params, exemplos). Publica com um clique em Docs > Publish. Descrições e examples salvos enriquecem a documentação.

// Collection > botão "Run"
// (ou Runner na sidebar)

// Configuração:
//   Environment: Dev
//   Iterations: 3 (repetições)
//   Delay: 200 ms entre requests
//   Data: ficheiro CSV/JSON

// Executa todos os requests em
// sequência e mostra um relatório
// com testes passados/falhados

O Runner executa toda a collection em sequência com testes. Configura iterations (repetições), delay entre requests e ficheiro de data (CSV/JSON). Mostra relatório com testes passados/falhados.

// Collection > Edit > Variables

// Exemplo:
//   base_url = https://api.exemplo.com
//   versao   = v2

// Usar em qualquer request:
// {{base_url}}/{{versao}}/users

// Todos os requests da collection
// partilham estas variáveis

// Alterar aqui muda em todo o lado

Variáveis de collection definem-se em Edit > Variables e ficam disponíveis em todos os requests via {{nome}}. Perfeitas para base_url — muda num sítio e atualiza tudo.

// Environments (sidebar) > "+"

// Ambiente "Dev":
//   base_url = http://localhost:8000
//   api_key  = chave-dev-123

// Ambiente "Prod":
//   base_url = https://api.exemplo.com
//   api_key  = chave-prod-xyz

// Ativar: dropdown no canto
// superior direito (olho = preview)

Cria um ambiente por contexto (Dev, Staging, Prod) com as suas variáveis. Ativa no dropdown do canto superior direito. O mesmo request funciona em todos os ambientes sem alterar nada.

// Tab "Pre-request" — corre
// ANTES de cada request:

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

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

// Útil para: tokens, hashes,
// dados dinâmicos, limpeza

O Pre-request Script corre antes do request — ideal para gerar timestamps, assinaturas HMAC ou preparar dados. Usa pm.environment.set() para guardar valores usados no request.

// Sintaxe: {{nome_variavel}}

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

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

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

// Variáveis ativas aparecem a
// laranja; inexistentes a vermelho

Variáveis usam a sintaxe {{nome}} em qualquer campo (URL, headers, body). Ficam a laranja quando resolvidas e a vermelho quando não existem. Passa o rato para ver o valor atual.

// Ambiente > Edit > Pre-request
// e > Tests (correm em TODOS os
// requests desse ambiente)

// Exemplo (Pre-request do env):
// garantir que há token antes
// de qualquer request:
if (!pm.environment.get("token")) {
  console.log("⚠️ Sem token!");
}

// Evita repetir scripts iguais
// em cada request da collection

Ambientes também têm Pre-request e Tests que correm em todos os requests desse ambiente. Perfeito para validações globais (ex.: garantir que existe token) sem repetir código em cada request.

// Ordem de resolução (maior vence):
// 1. Data       (ficheiro do Runner)
// 2. Local      (pm.variables.set)
// 3. Environment (ambiente ativo)
// 4. Collection (variáveis da col.)
// 5. Global     (visíveis em tudo)

// Exemplo: se "base_url" existe
// no ambiente E na collection,
// vence a do ambiente

// Debug: Console (Ctrl+Alt+C)
// mostra qual valor foi usado

Precedência (maior vence): Data > Local > Environment > Collection > Global. Se a mesma variável existe em vários scopes, vence o mais específico. O Console mostra o valor usado.

// Dropdown no canto superior direito
// > selecionar: Dev | Staging | Prod

// Alternância instantânea:
//   mesmo request, URLs diferentes

// "No Environment" = só variáveis
// de collection/globais ativas

// Ícone do olho (preview):
//   mostra valores do ambiente
//   sem o ativar

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

Alterna ambientes no dropdown do canto superior direito — o mesmo request passa a apontar para outra URL. O ícone do olho mostra valores sem ativar. Duplica um ambiente para criar variantes rapidamente.

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

// Úteis em bodies de teste:
// { "email": "{{$randomEmail}}" }

Variáveis dinâmicas ({{$guid}}, {{$timestamp}}, {{$randomEmail}}...) geram valores automáticos a cada execução. Ideais para criar dados de teste únicos sem scripts.

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

// Ler (respeita o scope):
const url = pm.variables.get("base_url");

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

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

// pm.variables.get() procura em
// todos os scopes automaticamente

Em scripts: pm.variables.get() lê respeitando o scope; pm.environment.set(), pm.collectionVariables.set() e pm.globals.set() guardam em scopes específicos. unset() apaga.

// Tab "Tests" — corre DEPOIS
// de receber a resposta:

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

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

// Resultados aparecem na tab
// "Tests" do painel de resposta

Testes escrevem-se na tab Tests com pm.test() — cada um aparece como passado/falhado no painel de resposta. Usam a sintaxe Chai (expect/should). Correm após cada resposta.

// Painel direito da tab Tests:
// "Snippets" — blocos prontos

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

// Clica num snippet e o código
// é inserido — ajusta os valores

// Pesquisa no topo filtra a lista

Os snippets (painel direito da tab Tests) são blocos de teste prontos a usar: status 200, JSON value check, response time, etc. Clica para inserir e ajusta os valores — ideal para começar rápido.

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

// Status entre vários:
pm.test("Sucesso", () => {
  pm.expect(pm.response.code)
    .to.be.oneOf([200, 201]);
});

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

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

Asserts comuns: to.have.status() verifica o código, oneOf([200, 201]) aceita vários, to.have.header() confirma headers e responseTime mede performance em ms.

// Valida a ESTRUTURA da resposta
// com tv4 (incluído no Postman):

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

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

Validação de schema confirma a estrutura (tipos, campos obrigatórios) em vez de valores exatos. Usa tv4 (incluído no Postman) com JSON Schema. Deteta breaking changes na API.

const json = pm.response.json();

pm.test("Nome correto", () => {
  pm.expect(json.nome).to.eql("Ana");
});

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

pm.test("Lista não vazia", () => {
  pm.expect(json.items)
    .to.have.lengthOf.above(0);
});

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

Converte a resposta com pm.response.json() e valida campos: to.eql() compara valores, to.be.a("number") verifica tipos, lengthOf.above(0) confirma arrays não vazios, to.have.property() verifica existência.

// Ficheiro dados.csv:
// nome,email
// Ana,ana@mail.com
// Rui,rui@mail.com

// No Runner: Data > selecionar CSV

// No body do request:
// { "nome": "{{nome}}",
//   "email": "{{email}}" }

// Cada iteração usa uma linha
// do ficheiro (2 linhas = 2 runs)

// pm.iterationData.get("nome")
// lê o valor atual em scripts

Data-driven testing: cria um CSV/JSON com uma linha por cenário e seleciona-o no Runner. Cada iteração usa valores diferentes via {{coluna}}. Em scripts, lê com pm.iterationData.get().

// Request 1 (Login) — tab 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}}

// O Runner executa em sequência
// e o token flui automaticamente

Padrão essencial: no teste do login, guarda o token com pm.environment.set(). Os requests seguintes usam {{token}} no header. No Runner, os dados fluem automaticamente entre requests.

// Apresenta a resposta como
// HTML personalizado:

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

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

// Ver em: Body > Visualize

O Visualizer renderiza a resposta como HTML custom com templates Handlebars. Define o template com pm.visualizer.set() nos Tests e vê o resultado na tab Visualize. Ótimo para relatórios legíveis.

// Tab "Authorization" do request

// Type: "No Auth"
//   (sem autenticação)

// Type: "Inherit auth from parent"
//   usa a auth da pasta ou
//   collection (padrão)

// Definir auth na collection:
//   Collection > Authorization
//   > Bearer Token {{token}}
//   Todos os requests herdam!

// Alterar o token num só lugar

No Auth envia sem credenciais. Inherit auth from parent (padrão) usa a auth da pasta ou collection. Definir auth ao nível da collection aplica-a a todos os requests — muda o token num só 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
// o browser para login e obtém
// o token automaticamente

OAuth 2.0 suporta vários grant types (Authorization Code, Client Credentials, etc.). Preenche Auth URL, Token URL, Client ID/Secret e clica Get New Access Token — o Postman trata do fluxo completo.

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

// Header gerado automaticamente:
// Authorization: Bearer eyJhbG...

// Fluxo típico:
// 1. Request de login (POST)
// 2. Teste guarda:
//    pm.environment.set("token",
//      pm.response.json().token)
// 3. Restantes requests usam
//    Bearer {{token}}

Bearer Token é o método mais comum em APIs modernas (JWT). Põe {{token}} no campo e o header Authorization: Bearer ... é gerado automaticamente. Combina com o teste do login que guarda o token.

// OAuth 1.0 (assinatura, sem token):
//   Consumer Key / Secret
//   Token / Token Secret
//   Signature Method: HMAC-SHA1
//   (usado por APIs antigas,
//    ex.: Twitter v1)

// Digest Auth:
//   Username / Password
//   (negocia challenge-response
//    com o servidor — mais seguro
//    que Basic, sem enviar a pass)

// Ambos geram headers automáticos

OAuth 1.0 assina requests com HMAC-SHA1 (APIs antigas). Digest Auth usa challenge-response sem enviar a password em claro — mais seguro que Basic. O Postman gera os headers complexos automaticamente.

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

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

// Atenção: base64 NÃO é
// encriptação — usar sempre
// sobre HTTPS em produção

Basic Auth envia utilizador e password codificados em base64 no header Authorization. Simples mas inseguro sem HTTPS — base64 é codificação, não encriptação.

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

Automação total: no Pre-request da collection, pm.sendRequest() faz login e guarda o token se não existir. Todos os requests ficam autenticados automaticamente sem intervenção manual.

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

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

// Ou em query (menos seguro):
// ?X-API-KEY=abc123xyz

// Guarda a chave numa variável
// de ambiente (nunca hardcoded)

API Key envia a chave num header custom (ex.: X-API-KEY) ou em query params. Escolhe Header (mais seguro). Guarda sempre o valor numa variável de ambiente, nunca hardcoded.

// Testar endpoints protegidos:

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

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

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

Testa a segurança: sem token deve devolver 401, token inválido 403. Podes descodificar o JWT (parte 2 em base64) e validar claims como role ou expiração.

# Windows:
# 1. Download em postman.com/downloads
# 2. Executar o instalador (.exe)
# 3. Abre automaticamente após instalar

# macOS:
brew install --cask postman

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

# Verificar versão:
# Help > About (no menu superior)

Descarrega em postman.com/downloads (Windows) ou usa brew (macOS) e snap (Linux). A app é gratuita com conta opcional. Atualizações são automáticas por padrão.

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

# Tab do request:
#   Params | Auth | Headers | Body
#   Pre-request | Tests | Settings

# Painel de resposta (em baixo):
#   Body | Cookies | Headers | Tests

# Barra inferior:
#   Console (Ctrl+Alt+C)
#   mostra todos os requests reais

A sidebar tem Collections, Environments e History. Cada request tem tabs para Params, Auth, Headers, Body e Tests. O Console (Ctrl+Alt+C) mostra o tráfego real — essencial para debug.

# Postman Web (browser):
#   web.postman.co
#   - Sem instalação
#   - Precisa do Postman Desktop Agent
#     para requests reais (CORS)

# Postman Desktop:
#   - Acesso total a rede local
#   - Interceptor e proxy nativos
#   - Melhor performance

# Ambos sincronizam via conta

A versão web corre no browser mas precisa do Desktop Agent para contornar CORS. A versão desktop tem acesso total à rede local. Tudo sincroniza pela conta Postman.

Ctrl + N          // novo request (tab)
Ctrl + Shift + N  // nova collection
Ctrl + S          // guardar request
Ctrl + Enter      // enviar request
Ctrl + Alt + C    // abrir Console
Ctrl + K          // pesquisa global
Ctrl + D          // duplicar tab
Ctrl + Shift + F  // formatar body JSON
Ctrl + [ / ]      // tab anterior/seguinte
Ctrl + Alt + N    // nova janela

Atalhos essenciais: Ctrl+Enter envia, Ctrl+S guarda, Ctrl+K pesquisa tudo, Ctrl+Shift+F formata JSON. Aceleram muito o trabalho diário.

# Criar conta:
#   postman.com > Sign Up (grátis)

# Workspaces (organização):
#   My Workspace    → pessoal
#   Team Workspace  → partilhado
#   Public          → visível a todos

# Criar workspace:
#   Workspaces > Create Workspace
#   > convidar membros por email

# Sync automático:
#   Collections, ambientes e testes
#   ficam disponíveis em todo o lado

A conta grátis permite workspaces pessoais e de equipa. Workspaces organizam collections por projeto/equipa. Tudo fica sincronizado na cloud automaticamente.

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

# Verificar:
newman --version

# Executar collection exportada:
newman run minha-collection.json

# Com ambiente:
newman run collection.json \
  -e ambiente.json

# Newman é o runner de linha de
# comandos do Postman — permite
# correr collections em CI/CD

Newman é o CLI oficial do Postman (instala via npm). Permite executar collections no terminal e em pipelines de CI/CD. Exporta a collection em JSON antes de correr.

# 1. Botão "+" ou Ctrl+N (novo tab)
# 2. Método: GET
# 3. URL: https://jsonplaceholder.typicode.com/users
# 4. Botão "Send" (ou Ctrl+Enter)

# Resposta aparece em baixo:
#   Status: 200 OK
#   Time: 145 ms
#   Body: JSON formatado

# Guardar:
#   Ctrl+S > escolher collection
#   (ou criar uma nova)

Cria um tab com Ctrl+N, escolhe o método GET, cola a URL e clica Send. A resposta mostra status, tempo e body. Guarda com Ctrl+S numa collection.

# Settings: ícone engrenagem (canto)

# Geral:
#   Request timeout: 0 (sem limite)
#   SSL verification: on/off
#   (off para certificados self-signed)

# Proxy:
#   Settings > Proxy
#   Usar proxy do sistema: on
#   Ou manual: host + porta

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

Em Settings configuras timeout, verificação SSL (desliga para certificados self-signed) e proxy. Certificados cliente adicionam-se em Certificates.

# Exportar collection (JSON v2.1)
# e executar:

newman run api-users.json

# Relatório no terminal:
#   ✓ Status é 200
#   ✗ Nome correto (falhou)
#   iterations, tempo, total

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

newman run executa a collection exportada e mostra testes passados/falhados no terminal. Instala newman-reporter-html para relatórios HTML partilháveis. Base para automatização.

// Collection > "..." > Monitor

// Configuração:
//   Nome: "API Prod - 5min"
//   Environment: Prod
//   Frequency: every 5 minutes
//   Notify: email em falha

// Executa a collection (com
// testes) periodicamente na cloud

// Histórico em:
//   Monitors > gráfico de uptime
//   e tempos de resposta

Monitors executam a collection na cloud em intervalos regulares (ex.: 5 min) e notificam por email em falhas. Dão histórico de uptime e tempos de resposta — monitorização contínua sem infraestrutura.

# Com ambiente exportado:
newman run col.json -e dev.json

# Com ficheiro de dados:
newman run col.json -d dados.csv

# Múltiplas iterações:
newman run col.json -n 5

# Timeout e opções:
newman run col.json \
  --timeout-request 5000 \
  --delay-request 200 \
  --bail   # parar na 1ª falha

Combina flags: -e (ambiente), -d (dados CSV/JSON), -n (iterações), --delay-request (pausa entre pedidos) e --bail (para na primeira falha). Espelha as opções do Runner.

// 1. Instalar extensão Chrome:
//    "Postman Interceptor"

// 2. No Postman desktop:
//    ícone satélite (canto inf. esq.)
//    > Interceptor > Connect

// 3. Navegar no browser — todos
//    os requests são capturados
//    para o Postman

// Filtrar por domínio:
//    Domain: api.exemplo.com

// Importar requests reais para
// debug ou criar collections

O Interceptor (extensão Chrome) captura requests reais do browser e envia-os para o Postman. Filtra por domínio. Perfeito para debug de APIs em produção e criar collections a partir de tráfego 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 testes de API no GitHub Actions: instala newman e corre a collection a cada push. O build falha se algum teste falhar. Funciona igual em GitLab CI, Jenkins ou qualquer CI com Node.

// O Postman pode atuar como proxy:
// Settings > Proxy > porta 5555

// Configurar o browser/app:
//   proxy: localhost:5555

// Todo o tráfego passa pelo
// Postman e fica no History

// Capturar requests de apps
// móveis (mesma rede WiFi):
//   usar o IP da máquina
//   como proxy no telemóvel

O Postman pode funcionar como proxy (Settings > Proxy): todo o tráfego que passa por ele fica no History. Serve para capturar requests de apps móveis na mesma rede — usa o IP da máquina como proxy.

// 1. Guardar exemplos nos requests:
//    Send > "Save as example"
//    (status + body esperados)

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

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

// Substitui a base_url:
// {{mock_url}}/users
// devolve os exemplos salvos

// Frontend trabalha sem backend!

Mock Servers simulam a API sem backend. Guarda examples (respostas esperadas) nos requests e cria o mock — a URL gerada devolve esses exemplos. Permite desenvolver o frontend em paralelo.

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

// Comentários:
//   selecionar texto > comentar
//   (como code review)

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

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

O API Builder parte do schema OpenAPI e gera collections validando requests contra o schema. Comentários, forks e pull requests trazem fluxo de code review para APIs. Roles controlam permissões.