Variable de Postman no persiste en Runner: Causa raíz y Solución

TL;DR

Las variables establecidas durante la ejecución manual de solicitudes suelen “desaparecer” cuando ejecutas la misma colección en el Collection Runner de Postman. La causa más común es una discrepancia de alcance: pm.environment.set depende de un entorno activo y el runner puede restablecer valores al finalizar. La solución práctica es elegir el alcance correcto (environment, collectionVariables, globals) y configurar explícitamente cómo deben persistir las variables.

Prueba Apidog hoy

Introducción

Estás probando una API manualmente en Postman:

1. Ejecutas una solicitud de login.
2. El script guarda un token.
3. Las siguientes solicitudes usan ese token.
4. Todo funciona.

Luego haces clic en Run Collection. El login responde correctamente, pero la siguiente solicitud falla con 401 Unauthorized. El token no está disponible.

Este problema aparece con frecuencia en Stack Overflow y en la comunidad de Postman. La respuesta corta suele ser “es un problema de alcance de variables”, pero para corregirlo de forma fiable conviene entender cómo Postman resuelve y persiste variables.

Jerarquía de alcance de variables en Postman

Postman tiene cinco alcances principales, de mayor a menor prioridad:

1. Variables locales: disponibles solo durante la ejecución del script actual.
2. Variables de datos: cargadas desde un archivo CSV o JSON en ejecuciones data-driven.
3. Variables de colección: disponibles dentro de una colección.
4. Variables de entorno: disponibles en el entorno seleccionado.
5. Variables globales: disponibles en cualquier colección y entorno.

Cuando Postman encuentra una referencia como:

{{token}}

busca la variable en ese orden y usa la primera coincidencia.

Por eso, si tienes un token definido en más de un alcance, puede que Postman no esté usando el valor que esperas.

Por qué las variables desaparecen en el Collection Runner

1. Diferencia entre valor inicial y valor actual

Cada variable de Postman tiene dos campos:

• Initial value: se sincroniza y puede compartirse con el equipo.
• Current value: es local en tu máquina y no se sincroniza.

Cuando ejecutas este código:

pm.environment.set('token', value);

Postman actualiza el current value del entorno activo.

En modo manual, esto suele funcionar porque sigues usando la misma sesión local de Postman. Pero en el Collection Runner, la ejecución parte de un estado inicial del entorno y puede restablecer los cambios al terminar.

2. pm.environment.set requiere un entorno activo

Este patrón es muy común:

pm.environment.set('token', pm.response.json().access_token);

El problema: pm.environment.set escribe en el entorno activo.

Si ejecutas la colección sin seleccionar un entorno, no hay dónde guardar la variable. El resultado práctico es que el token no queda disponible como esperas.

Antes de usar pm.environment.set, verifica que el runner tenga un entorno seleccionado.

3. El runner puede descartar cambios al finalizar

El Collection Runner tiene una opción llamada Keep variable values.

Si está desmarcada, los cambios hechos durante la ejecución pueden descartarse al finalizar. Es decir:

• La variable puede estar disponible durante la misma ejecución.
• Pero no queda guardada después de que el runner termina.

Esto explica por qué una colección puede funcionar parcialmente durante el runner, pero luego no ves el token en el panel del entorno.

Soluciones prácticas

Solución 1: activa “Keep variable values” en el runner

Antes de ejecutar la colección:

1. Abre el Collection Runner.
2. Selecciona el entorno correcto.
3. Busca la opción Keep variable values.
4. Actívala.
5. Ejecuta la colección.

Esto indica a Postman que conserve los cambios de variables realizados durante la ejecución.

Úsalo cuando quieras que el runner actualice el estado del entorno, por ejemplo:

• tokens de autenticación;
• IDs generados durante pruebas;
• valores reutilizados por ejecuciones posteriores.

Evítalo si estás ejecutando múltiples iteraciones y no quieres que una iteración contamine la siguiente.

Solución 2: usa variables de colección para estado interno de la colección

Si el token solo se usa dentro de la misma colección, normalmente es mejor usar variables de colección.

En el script de post-respuesta del login:

const json = pm.response.json();

pm.collectionVariables.set('token', json.access_token);

En solicitudes posteriores:

const token = pm.collectionVariables.get('token');

pm.request.headers.upsert({
  key: 'Authorization',
  value: `Bearer ${token}`
});

O directamente en la pestaña Authorization/Header:

Bearer {{token}}

Las variables de colección son útiles porque:

• no dependen de que haya un entorno seleccionado;
• están ligadas a la colección;
• son apropiadas para valores creados y consumidos dentro de una misma ejecución.

Solución 3: comprueba que el entorno esté seleccionado

Si necesitas usar variables de entorno, asegúrate de seleccionar uno antes de ejecutar.

Checklist rápido:

1. Abre el Collection Runner.
2. Revisa el selector Environment.
3. Selecciona el entorno correcto.
4. Ejecuta la colección.
5. Abre la consola para verificar que el valor se haya establecido.

Ejemplo de script defensivo:

const token = pm.response.json().access_token;

if (!pm.environment.name) {
  console.warn('No hay entorno activo. Considera usar pm.collectionVariables.set.');
} else {
  pm.environment.set('token', token);
}

Solución 4: usa valores iniciales para variables obligatorias

Para variables que deben existir desde la primera solicitud, como baseUrl, no dependas solo del current value.

Configúralas también como initial value:

baseUrl = https://api.example.com

Esto es importante cuando:

• otra persona del equipo ejecuta la colección;
• ejecutas la colección en CI;
• usas Newman;
• importas/exportas entornos.

Si solo defines el valor actual en tu máquina, otros contextos pueden iniciar con la variable vacía.

Solución 5: depura con console.log

Agrega logs en scripts de pre-request y post-response para confirmar desde qué alcance se está leyendo la variable.

Ejemplo:

console.log('collection token:', pm.collectionVariables.get('token'));
console.log('environment token:', pm.environment.get('token'));
console.log('global token:', pm.globals.get('token'));

También puedes inspeccionar qué valor resolvería Postman para {{token}}:

console.log('resolved token:', pm.variables.get('token'));

Abre la consola desde:

View > Show Postman Console

Luego ejecuta la colección y revisa el orden real de lectura y escritura.

Patrón recomendado para tokens de autenticación

Para una colección típica con login y endpoints protegidos, usa este patrón.

Request: Login

Script de post-respuesta:

const response = pm.response.json();

pm.test('login devuelve access_token', function () {
  pm.expect(response.access_token).to.be.a('string');
});

pm.collectionVariables.set('token', response.access_token);

Requests protegidas

Header:

Authorization: Bearer {{token}}

Opcionalmente, agrega una validación en pre-request:

const token = pm.collectionVariables.get('token');

if (!token) {
  throw new Error('Falta token. Ejecuta primero la solicitud de login.');
}

Este enfoque evita depender del entorno cuando el token solo es necesario dentro de la colección.

Cómo Apidog maneja el alcance de variables

Apidog utiliza una jerarquía de variables compatible con el flujo habitual de pruebas de API: global, entorno, colección y local.

La diferencia práctica está en la interfaz. En el editor de variables de Apidog, los valores iniciales y actuales se muestran de forma explícita, lo que reduce el riesgo de configurar solo un valor local por accidente.

Además, Apidog admite sintaxis compatible con Postman, por ejemplo:

pm.environment.set('token', value);
pm.environment.get('token');

pm.collectionVariables.set('token', value);
pm.collectionVariables.get('token');

Esto permite migrar colecciones que ya usan scripts de Postman y mantener el mismo modelo mental de ejecución.

En el ejecutor de pruebas de Apidog, el estado de variables entre pasos se preserva durante la ejecución salvo que configures otro comportamiento. Esto se acerca más a lo que muchos desarrolladores esperan cuando pasan de pruebas manuales a ejecuciones automatizadas.

Resumen de errores comunes

Error	Síntoma	Solución
No se seleccionó ningún entorno	pm.environment.set no guarda donde esperas	Seleccionar un entorno o usar variables de colección
Solo se estableció el valor actual	La variable falta en CI o en la máquina de un compañero	Definir también el valor inicial
“Keep variable values” está desmarcado	Las variables se restablecen al finalizar el runner	Activar “Keep variable values”
Usar variables de entorno para estado interno	Funciona manualmente, falla en el runner	Cambiar a pm.collectionVariables.set
Hay variables con el mismo nombre en varios alcances	Postman usa un valor inesperado	Loguear pm.variables, pm.environment, pm.collectionVariables y revisar prioridad
El login no valida el token antes de guardarlo	Se guarda undefined como token	Agregar tests y validaciones antes de set

Preguntas frecuentes

¿Por qué pm.environment.set funciona manualmente pero falla en el runner?

Porque en modo manual normalmente trabajas dentro de una sesión persistente con un entorno seleccionado. En el runner, el entorno se carga al inicio de la ejecución y puede restablecerse al finalizar si no activas Keep variable values.

¿Cuál es la diferencia entre pm.environment.set y pm.collectionVariables.set?

pm.environment.set escribe en el entorno activo. Ese valor puede ser usado por varias colecciones que compartan el mismo entorno.

pm.collectionVariables.set escribe en el alcance de la colección. Es más adecuado para valores que solo se usan dentro de esa colección, como un token temporal generado por una solicitud de login.

¿Este problema también ocurre en Newman?

Sí. Newman usa el mismo modelo de alcance. Por defecto, una ejecución parte de los valores del entorno exportado y no persiste automáticamente los cambios al finalizar.

Para guardar el estado final del entorno, usa:

newman run collection.json \
  -e environment.json \
  --export-environment environment.updated.json

Luego puedes usar environment.updated.json en la siguiente ejecución.

¿Qué hace --export-environment en Newman?

Escribe el estado final del entorno en un archivo JSON, incluyendo variables modificadas durante la ejecución. Es útil en pipelines donde una ejecución genera valores que otra ejecución necesita reutilizar.

¿Apidog es compatible con pm.collectionVariables.set?

Sí. Apidog admite APIs de scripting compatibles con Postman, incluyendo:

pm.collectionVariables.set('token', value);
pm.collectionVariables.get('token');
pm.environment.set('token', value);
pm.environment.get('token');

¿Cómo paso variables de una colección a otra en Postman?

Puedes usar variables globales:

pm.globals.set('token', value);

Pero úsalas con cuidado. Las variables globales no están limitadas a una colección o entorno específico, por lo que pueden causar colisiones de nombres o resultados difíciles de depurar.

Conclusión

Si una colección pasa manualmente pero falla en el runner, revisa primero el alcance de variables.

Regla práctica:

• Usa pm.collectionVariables.set para valores internos de una colección.
• Usa pm.environment.set cuando el valor pertenece a un entorno concreto.
• Activa Keep variable values si necesitas conservar cambios después del runner.
• Define initial values para variables requeridas desde el inicio.
• Usa console.log para confirmar qué alcance contiene cada valor.

Entender estos puntos elimina la mayoría de falsos negativos causados por variables “perdidas” en Postman.