TL;DR
Postman restringió el acceso a Collection Runner en su nivel gratuito, lo que afecta la ejecución automatizada de pruebas para equipos que no han actualizado su plan. El cambio impacta pruebas locales, pipelines CI/CD y flujos que usaban Runner para ejecutar solicitudes en lote. En esta guía verás qué cambió, qué se rompe en la práctica y cómo usar el runner de Apidog sin límites mensuales de ejecución.
Introducción
Collection Runner de Postman era una pieza clave en muchos flujos de pruebas API. Permitía tomar una colección con decenas de solicitudes, ejecutarlas en secuencia, compartir variables entre requests, validar respuestas con aserciones y revisar un resumen final.
El problema aparece con las restricciones de 2026. Como parte de la reducción del nivel gratuito, Postman limitó el acceso a Collection Runner. Las cuentas gratuitas ya no pueden ejecutar colecciones más allá de cierto número de solicitudes por mes, y algunas funciones del Runner quedaron detrás de planes pagos.
En la práctica, esto afecta a equipos que usan Postman para:
- Pruebas de humo antes de hacer merge.
- Validaciones antes de desplegar a staging o producción.
- Pipelines CI/CD basados en Newman.
- Flujos API de varios pasos con variables compartidas.
- Ejecuciones repetidas para pruebas básicas de carga.
Lo que Postman cambió en Collection Runner
El nivel gratuito de Postman ahora restringe Collection Runner principalmente en tres áreas.
1. Límites mensuales de ejecución
Las cuentas gratuitas tienen un límite en la cantidad de ejecuciones de Collection Runner disponibles por mes. Postman no ha publicado el número exacto de forma clara, pero reportes de la comunidad lo ubican cerca de 25 ejecuciones mensuales.
Para un equipo que ejecuta pruebas varias veces al día, ese límite puede agotarse en pocos días.
2. Restricciones en Newman CLI
Newman, la CLI open source para ejecutar colecciones de Postman desde terminal o CI, antes funcionaba con cualquier exportación de colección sin depender del plan de Postman.
Después de 2026, algunas funciones de Newman se vinculan al nivel del plan cuando se usan colecciones sincronizadas en la nube.
3. Ejecución visual de pruebas
El Collection Runner visual, disponible desde la barra lateral de Postman, muestra restricciones o bloqueo por plan cuando la cuenta gratuita alcanza el límite de ejecución.
Lo que sigue sin estar restringido es la ejecución manual de solicitudes individuales. Es decir, hacer clic en Send dentro de una sola request continúa disponible. El bloqueo apunta específicamente a ejecuciones automatizadas por lotes.
Qué se rompe en la práctica
Pruebas de humo pre-commit y pre-deploy
Muchos equipos ejecutan una colección de pruebas antes de fusionar una PR o desplegar a staging.
Ejemplo:
- Colección de smoke tests: 30 requests.
- Equipo: 3 desarrolladores.
- Frecuencia: 2 ejecuciones por persona al día.
Con ese patrón, el límite mensual gratuito puede agotarse aproximadamente en dos días.
Pipelines CI/CD
Los pipelines basados en Newman son de los más afectados. Un flujo típico en GitHub Actions puede verse así:
- name: Run API tests
run: newman run ./collections/api-tests.json -e ./environments/staging.json
Cuando se alcanza el límite de la cuenta, el pipeline puede empezar a fallar o encontrar errores de límite de uso.
Esto es especialmente problemático si tienes varios pipelines que se ejecutan en cada push, PR o despliegue.
Suites end-to-end basadas en API
Algunos equipos modelan flujos completos en Postman:
- Autenticarse.
- Guardar el token.
- Crear un recurso.
- Consultar el recurso.
- Actualizarlo.
- Eliminarlo.
En Postman, este patrón suele implementarse con variables:
pm.environment.set("auth_token", pm.response.json().token);
Luego, otras requests usan esa variable:
Authorization: Bearer {{auth_token}}
Con Runner restringido, estos flujos deben ejecutarse manualmente request por request si no tienes acceso al runner completo.
Pruebas básicas de carga y rendimiento
Collection Runner permite configurar iteraciones y retrasos para ejecutar una colección varias veces en secuencia.
Esto se usa a menudo para pruebas simples como:
- Ejecutar una colección 100 veces.
- Añadir un delay entre requests.
- Validar estabilidad de respuestas.
- Detectar errores intermitentes.
Con límites de ejecución, este caso de uso deja de ser viable en el nivel gratuito.
Soluciones inmediatas dentro de Postman
Si todavía no quieres cambiar de herramienta, puedes aplicar algunas soluciones temporales dentro del ecosistema de Postman.
Exportar la colección y ejecutar Newman localmente
Newman puede ejecutar una colección exportada como JSON sin iniciar sesión en una cuenta de Postman, siempre que no dependas de funciones conectadas a la nube.
Exporta tu colección y entorno, luego ejecuta:
newman run collection.json -e environment.json
Esto evita el límite de ejecución asociado a la cuenta porque Newman lee archivos locales.
La desventaja es operativa: pierdes sincronización con el workspace activo de Postman. Cada cambio en la colección requiere una nueva exportación.
Dividir colecciones grandes
Si tienes una colección grande, puedes dividirla en partes más pequeñas.
Por ejemplo:
api-tests-full.json
Puede separarse en:
api-tests-auth.json
api-tests-users.json
api-tests-orders.json
api-tests-billing.json
Esto puede ayudarte a reducir el impacto del límite, pero no es una solución robusta. También rompe flujos lógicos cuando las requests dependen unas de otras.
Actualizar solo una cuenta
Si una sola cuenta ejecuta los pipelines CI/CD, puedes actualizar únicamente esa cuenta a un plan pago mientras el resto del equipo mantiene cuentas gratuitas.
Este enfoque reduce el costo frente a actualizar a todo el equipo, pero mantiene la dependencia del límite y del modelo de plan.
Cómo funciona de manera diferente el runner de Apidog
El runner de Apidog, disponible como Escenarios de prueba o desde el botón Ejecutar en una colección, no tiene límites mensuales de ejecución en ningún plan, incluido el gratuito.
Comparación práctica:
| Característica | Postman gratuito | Apidog gratuito |
|---|---|---|
| Ejecuciones del Runner/mes | ~25 reportadas | Ilimitado |
| Ejecuciones CI/CD con CLI | Limitado | Ilimitado |
| Iteraciones por ejecución | Limitado | Ilimitado |
| Encadenamiento de requests con variables | Limitado | Ilimitado |
| Aserciones de prueba | Disponible | Disponible |
| Informe resumen de ejecución | Disponible | Disponible |
Apidog también ofrece una CLI, apidog-cli, para integrarse en pipelines CI/CD de forma similar a Newman.
Ejemplo de comando:
apidog run {project-id} --collection {collection-id} --environment {env-id}
También puedes exportar una colección de Apidog y ejecutarla sin conexión, de forma similar al flujo con archivos locales de Newman, pero sin depender de restricciones basadas en la cuenta.
Configurar Apidog CLI en GitHub Actions
Si estás migrando desde Newman, el cambio en CI suele ser pequeñ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
Después: 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 }}
Las diferencias principales son:
- Apidog usa un token de acceso.
- La ejecución puede referenciar proyectos y entornos.
- Puedes generar salida JSON para procesar resultados.
- El pipeline no depende de un límite mensual de ejecuciones.
Guarda el token como secreto en GitHub Actions:
APIDOG_ACCESS_TOKEN
Luego consúmelo desde el workflow:
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
Mantener Newman mientras migras
Si tu equipo ya tiene scripts alrededor de Newman, puedes migrar de forma gradual.
Una opción es:
- Mantener Apidog como herramienta principal de diseño y pruebas.
- Exportar la colección como JSON compatible con Postman.
- Ejecutar Newman con el archivo exportado.
Ejemplo:
newman run apidog-exported-collection.json -e staging.environment.json
Este enfoque te permite seguir usando comandos existentes mientras el equipo adopta Apidog en el flujo diario.
Funciones avanzadas del runner en Apidog
Además de cubrir los casos afectados por las restricciones de Postman, el runner de Apidog incluye funciones útiles para pruebas automatizadas.
Pruebas basadas en datos
Puedes importar un archivo CSV o JSON para ejecutar la misma colección con distintos valores.
Ejemplo CSV:
email,password,expectedStatus
user1@example.com,password123,200
user2@example.com,badpass,401
user3@example.com,password123,200
Cada fila se convierte en una iteración de prueba.
Este patrón es útil para validar:
- Login con múltiples usuarios.
- Casos positivos y negativos.
- Permisos por rol.
- Diferentes payloads de entrada.
Iteraciones personalizadas
Puedes definir un número específico de iteraciones para una ejecución.
Ejemplos de uso:
- Ejecutar una colección 50 veces para detectar errores intermitentes.
- Ejecutar 500 iteraciones para una prueba de estrés básica.
- Repetir el mismo flujo con distintos datos de entrada.
Encadenamiento de requests con variables
Puedes guardar valores de una respuesta y reutilizarlos en requests posteriores.
Flujo típico:
- Login.
- Guardar token.
- Crear recurso.
- Guardar
resource_id. - Consultar, actualizar o eliminar ese recurso.
Este patrón permite probar flujos reales de API sin ejecutar cada request manualmente.
Integración con Smart Mock
El runner puede interactuar con el servidor de mocks incorporado de Apidog.
Esto permite ejecutar pruebas contra endpoints simulados sin levantar un backend separado.
Es útil cuando:
- El frontend necesita probar contra una API aún no implementada.
- El backend está incompleto.
- Quieres validar contratos antes de desarrollar la lógica real.
- Necesitas datos consistentes para pruebas automatizadas.
Ejecuciones programadas
Apidog permite configurar ejecuciones automáticas en un horario, por ejemplo:
- Cada hora.
- Una vez al día.
- Antes de una ventana de despliegue.
- Como validación recurrente de staging.
Los resultados quedan disponibles en el historial de pruebas del proyecto.
Checklist para migrar desde Postman Runner
Si quieres reducir fricción, migra en pasos:
- Identifica las colecciones que se ejecutan en CI/CD.
- Exporta las colecciones y entornos actuales.
- Replica los entornos en Apidog.
- Valida variables críticas como tokens, IDs y URLs base.
- Ejecuta la colección manualmente en Apidog.
- Configura
apidog-clien CI. - Guarda
APIDOG_ACCESS_TOKENcomo secreto. - Genera salida JSON para reportes.
- Compara resultados con el pipeline anterior.
- Retira Newman cuando el flujo esté estable.
Conclusión
Las restricciones de Collection Runner en Postman afectan directamente a equipos que dependen de pruebas automatizadas en el nivel gratuito, especialmente en CI/CD, smoke tests y flujos API de varios pasos.
La solución temporal es exportar colecciones y ejecutar Newman localmente, pero eso agrega mantenimiento manual y rompe la sincronización con el workspace.
Si necesitas un runner sin límites mensuales, Apidog cubre los casos principales: ejecución de colecciones, variables entre requests, aserciones, iteraciones, ejecución por CLI y uso en pipelines. Para equipos que ya tienen CI configurado, la migración suele requerir solo ajustes en autenticación, referencias de proyecto y comandos de ejecución.
Top comments (0)