DEV Community

Cover image for Restrições do Postman Collection Runner: O que Mudou e Como Contornar
Lucas
Lucas

Posted on • Originally published at apidog.com

Restrições do Postman Collection Runner: O que Mudou e Como Contornar

TL;DR

O Postman restringiu o acesso ao Collection Runner no plano gratuito, afetando execuções automatizadas de testes, pipelines de CI/CD e fluxos que dependiam da execução em lote de requisições. Na prática, equipes que usavam o Runner para testes locais, smoke tests, suítes ponta a ponta ou Newman em CI precisam adaptar o fluxo ou migrar para um runner sem limite mensal, como o runner do Apidog.

Experimente o Apidog hoje

Introdução

O Collection Runner do Postman sempre foi uma das funcionalidades mais úteis para testes de API. Você podia criar uma coleção com dezenas de requisições, clicar em Run Collection e executar tudo em sequência, com:

  • variáveis compartilhadas entre requisições;
  • scripts de teste em cada resposta;
  • encadeamento de chamadas;
  • relatório final da execução.

Para fluxos multi-etapas, como autenticação, criação de recurso, validação e limpeza, isso era essencial.

Com as restrições de 2026 no plano gratuito, o Postman passou a limitar o uso do Collection Runner. Contas gratuitas não conseguem mais executar coleções livremente além de um determinado volume mensal, e algumas funcionalidades do Runner passaram a ficar bloqueadas por paywall.

O impacto aparece principalmente em três cenários:

  1. testes locais executados várias vezes ao dia;
  2. pipelines de CI/CD baseados em Newman;
  3. fluxos de teste que dependem de execução em lote.

O que o Postman mudou no Collection Runner

O plano gratuito do Postman passou a restringir o Collection Runner em alguns pontos importantes.

1. Limites mensais de execução

Contas gratuitas têm um limite mensal de execuções do Collection Runner. O Postman não publicou esse número de forma clara, mas relatos da comunidade estimam algo em torno de 25 execuções por mês.

Para uma equipe pequena, esse limite pode acabar rapidamente. Por exemplo:

  • 3 desenvolvedores;
  • 2 execuções por dia por pessoa;
  • 6 execuções diárias no total.

Nesse ritmo, o limite estimado seria consumido em poucos dias.

2. Restrições no Newman CLI

O Newman é o runner de linha de comando usado para executar coleções do Postman no terminal ou em pipelines de CI.

Antes, era comum rodar algo assim:

newman run ./collections/api-tests.json -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Com as mudanças, alguns fluxos que usam coleções sincronizadas na nuvem podem ficar vinculados ao plano da conta Postman. Isso afeta especialmente times que dependem de execução automatizada no CI/CD.

3. Runner visual bloqueado após o limite

O Collection Runner visual, acessado pela interface do Postman, pode exibir estado de paywall em contas gratuitas depois que o limite mensal é atingido.

O que continua disponível: executar requisições individuais manualmente com Send. A restrição mira principalmente a execução automatizada em lote.

O que quebra na prática

Testes de fumaça pré-commit e pré-deploy

Muitas equipes executam uma coleção de smoke tests antes de abrir um PR, fazer merge ou publicar em staging.

Exemplo de fluxo comum:

  1. autenticar usuário;
  2. criar recurso;
  3. consultar recurso criado;
  4. atualizar recurso;
  5. remover recurso;
  6. validar resposta final.

Se essa coleção tem 30 requisições e é executada várias vezes ao dia, o limite gratuito pode ser atingido rapidamente.

Pipelines de CI/CD

Pipelines baseados em Newman são um dos casos mais sensíveis.

Um workflow do GitHub Actions como este:

- name: Run API tests
  run: newman run ./collections/api-tests.json -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

pode começar a falhar quando o limite da conta for atingido ou quando recursos dependentes da conta ficarem indisponíveis.

Isso é especialmente problemático quando o pipeline roda em cada push, pull request ou deploy.

Suítes ponta a ponta com encadeamento de variáveis

Muitas coleções usam scripts como:

pm.environment.set("access_token", pm.response.json().token);
Enter fullscreen mode Exit fullscreen mode

Depois, a próxima requisição usa esse token:

Authorization: Bearer {{access_token}}
Enter fullscreen mode Exit fullscreen mode

Sem um Runner disponível, o desenvolvedor precisa executar as requisições manualmente, uma por uma, o que torna o teste mais lento e mais propenso a erro.

Testes básicos de carga e desempenho

O Collection Runner também permitia configurar:

  • número de iterações;
  • delay entre requisições;
  • repetição de coleções.

Isso era útil para testes simples de carga, por exemplo:

  • executar uma coleção 100 vezes;
  • validar estabilidade de endpoints;
  • observar comportamento sob chamadas repetidas.

Com limites de execução no plano gratuito, esse tipo de teste deixa de ser viável para muitos times.

Soluções imediatas dentro do Postman

Se você ainda não quer migrar de ferramenta, existem algumas alternativas dentro do ecossistema Postman.

1. Exportar coleção e ambiente para rodar Newman localmente

Você pode exportar a coleção e o ambiente como arquivos JSON e executar o Newman offline:

newman run collection.json -e environment.json
Enter fullscreen mode Exit fullscreen mode

Isso evita depender da coleção sincronizada na nuvem.

Exemplo com relatório JSON:

newman run collection.json \
  -e environment.json \
  --reporters cli,json \
  --reporter-json-export results.json
Enter fullscreen mode Exit fullscreen mode

Limitação: sempre que a coleção mudar, será necessário exportar novamente.

2. Dividir coleções grandes

Se você tem uma coleção muito grande, pode dividi-la em coleções menores.

Por exemplo:

api-tests/
├── auth-tests.json
├── user-tests.json
├── billing-tests.json
└── cleanup-tests.json
Enter fullscreen mode Exit fullscreen mode

Isso pode ajudar a organizar a execução, mas não resolve o problema principal. Além disso, pode quebrar fluxos que dependem de estado compartilhado entre requisições.

3. Atualizar apenas a conta usada no CI

Se somente uma conta executa os testes automatizados no pipeline, uma opção é manter essa conta em plano pago e deixar as demais em plano gratuito.

Esse modelo reduz custo, mas cria uma dependência centralizada: se essa conta falhar, o CI também falha.

Como o Collection Runner do Apidog funciona de forma diferente

No Apidog, o runner pode ser usado via Test Scenarios ou pelo botão Run em uma coleção. Segundo o conteúdo original, ele não aplica limites mensais de execução em nenhum plano, incluindo o plano gratuito.

Comparação direta:

Funcionalidade Postman gratuito Apidog gratuito
Execuções do Runner por mês ~25, segundo relatos Ilimitado
Execuções de CI/CD via CLI Limitado Ilimitado
Iterações por execução Limitado Ilimitado
Encadeamento de requisições com variáveis Limitado Ilimitado
Asserções de teste Disponível Disponível
Relatório de resumo da execução Disponível Disponível

O runner CLI do Apidog, apidog-cli, pode ser usado em CI/CD de forma parecida com o Newman.

Exemplo de comando:

apidog run {project-id} --collection {collection-id} --environment {env-id}
Enter fullscreen mode Exit fullscreen mode

Você também pode exportar uma coleção do Apidog e executá-la offline, de forma semelhante ao fluxo local com Newman.

Configurando o runner do Apidog no GitHub Actions

Se o seu pipeline atual usa Newman, a migração pode ser feita trocando a instalação e o comando de execução.

Antes: Newman 

- name: Install Newman
  run: npm install -g newman

- name: Run API tests
  run: newman run ./collections/api-tests.json -e ./environments/staging.json --reporters cli,json --reporter-json-export results.json
Enter fullscreen mode Exit fullscreen mode

Depois: Apidog CLI 

- name: Install Apidog CLI
  run: npm install -g apidog-cli

- name: Run API tests
  run: apidog run --project {project-id} --env {env-id} --output results.json
  env:
    APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
Enter fullscreen mode Exit fullscreen mode

As principais diferenças são:

  • o Apidog usa um token de acesso;
  • a execução referencia projeto e ambiente;
  • o resultado pode ser exportado para JSON;
  • o token deve ser armazenado como secret no CI.

No GitHub Actions, configure o segredo em:

Settings > Secrets and variables > Actions > New repository secret
Enter fullscreen mode Exit fullscreen mode

Nome sugerido:

APIDOG_ACCESS_TOKEN
Enter fullscreen mode Exit fullscreen mode

Depois, use no workflow:

env:
  APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
Enter fullscreen mode Exit fullscreen mode

Alternativa: continuar usando Newman com coleção exportada do Apidog

Se sua equipe prefere manter o Newman no pipeline, outra opção é exportar a coleção do Apidog em formato compatível com Postman e continuar executando o Newman localmente.

Exemplo:

newman run ./collections/apidog-export.json -e ./environments/staging.json
Enter fullscreen mode Exit fullscreen mode

Esse fluxo é útil quando você quer:

  • manter scripts existentes;
  • evitar reescrever o pipeline de uma vez;
  • migrar gradualmente a gestão das APIs para o Apidog;
  • continuar usando execução offline.

Funcionalidades avançadas do runner no Apidog

Além da execução básica de coleções, o runner do Apidog também cobre cenários mais avançados de teste.

Testes orientados a dados

Você pode importar um arquivo CSV ou JSON para executar a mesma coleção com múltiplos conjuntos de dados.

Exemplo de CSV:

email,password,expectedStatus
user1@example.com,123456,200
user2@example.com,wrong-password,401
Enter fullscreen mode Exit fullscreen mode

A coleção pode usar variáveis como:

{{email}}
{{password}}
{{expectedStatus}}
Enter fullscreen mode Exit fullscreen mode

Cada linha do arquivo vira uma iteração.

Iterações personalizadas

Você pode configurar quantas vezes uma coleção deve ser executada.

Exemplo de uso:

  • 10 execuções para validação rápida;
  • 100 execuções para teste repetitivo;
  • 500 execuções para um teste básico de estresse.

Isso é útil para validar estabilidade de endpoints sem depender de um contador mensal.

Integração com Smart Mock

Durante a execução dos testes, o runner pode interagir com o servidor de mock integrado do Apidog.

Esse fluxo ajuda quando:

  • a API real ainda não foi implementada;
  • o frontend precisa testar integração;
  • você quer simular respostas específicas;
  • não deseja subir um servidor mock separado.

Execuções agendadas

Você também pode configurar execuções automáticas em intervalos recorrentes, como:

  • a cada hora;
  • diariamente;
  • semanalmente.

Os resultados ficam disponíveis no histórico de testes do projeto, o que facilita acompanhar regressões ao longo do tempo.

Checklist de migração de Newman para Apidog CLI

Use este checklist para migrar com menos risco:

  1. Identifique as coleções críticas

    • smoke tests;
    • testes de autenticação;
    • testes de CRUD;
    • suítes usadas no CI/CD.

  2. Mapeie ambientes

    • local;
    • staging;
    • produção;
    • variáveis sensíveis.

  3. Configure o token do Apidog no CI

    • crie o access token;
    • salve como secret;
    • injete via variável de ambiente.

  4. Substitua o comando no pipeline

    • remova newman run;
    • adicione apidog run;
    • mantenha exportação de resultado se necessário.

  5. Valide o output

    • confira status de saída;
    • valide relatório JSON;
    • confirme falha do pipeline quando testes falharem.

  6. Rode em paralelo temporariamente

    • execute Newman e Apidog no mesmo pipeline por alguns dias;
    • compare resultados;
    • remova o fluxo antigo quando estiver estável.

Conclusão

As restrições do Collection Runner do Postman criam um bloqueio prático para equipes que dependem de testes automatizados no plano gratuito, principalmente em pipelines de CI/CD e suítes multi-etapas.

Para contornar o problema, você pode exportar coleções e rodar Newman localmente, dividir suítes ou atualizar uma conta específica. Porém, essas alternativas adicionam manutenção ou custo.

Se o objetivo é manter execução automatizada sem limite mensal, o runner do Apidog cobre os principais casos de uso: execução de coleções, variáveis, asserções, iterações, CI/CD e relatórios. A migração a partir de um pipeline Newman geralmente exige apenas troca do CLI, configuração de token e ajuste dos IDs de projeto e ambiente.

Top comments (0)