DEV Community

Cover image for Postman Variable im Postman Runner nicht persistent: Ursache und Lösung
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Postman Variable im Postman Runner nicht persistent: Ursache und Lösung

TL;DR

Variablen, die beim manuellen Ausführen von Postman-Requests funktionieren, fehlen im Collection Runner oft wegen eines Scope-Mismatchs. Prüfen Sie zuerst, ob eine Umgebung ausgewählt ist, ob der Runner Variablenwerte nach dem Lauf zurücksetzt und ob Sie für Laufzeitwerte besser pm.collectionVariables.set statt pm.environment.set verwenden sollten.

Apidog noch heute ausprobieren

Einleitung

Ein typischer Ablauf sieht so aus:

  1. Sie führen eine Login-Anfrage manuell in Postman aus.
  2. Ein Script speichert das Access Token.
  3. Die nächste Anfrage verwendet {{token}}.
  4. Manuell funktioniert alles.
  5. Im Collection Runner schlägt die nächste Anfrage mit 401 Unauthorized fehl.

Das Problem liegt meistens nicht am Auth-Endpoint, sondern am Variablenbereich und daran, wie Postman Werte im Runner lädt, überschreibt oder nach dem Lauf zurücksetzt.

Dieser Leitfaden zeigt:

  • welche Variablenbereiche Postman verwendet
  • warum pm.environment.set() im Runner anders wirken kann als im manuellen Modus
  • welche Fixes Sie konkret anwenden können
  • wann Collection Variables die bessere Wahl sind
  • wie Sie das Verhalten mit Logs debuggen

Die Variablenbereichshierarchie von Postman

Postman löst Variablen nach Priorität auf. Wenn Sie {{token}} verwenden, sucht Postman in dieser Reihenfolge:

  1. Lokale Variablen

    Nur innerhalb der aktuellen Script-Ausführung verfügbar.

  2. Datenvariablen

    Werte aus CSV- oder JSON-Dateien für datengesteuerte Runs.

  3. Sammlungsvariablen

    An eine Collection gebunden und innerhalb dieser Collection verfügbar.

  4. Umgebungsvariablen

    An die aktive Umgebung gebunden und über Collections hinweg verwendbar.

  5. Globale Variablen

    In allen Collections und Umgebungen verfügbar.

Wenn mehrere Bereiche eine Variable mit demselben Namen enthalten, gewinnt der Bereich mit der höheren Priorität.

Beispiel:

Collection Variable: token = abc
Environment Variable: token = xyz
Enter fullscreen mode Exit fullscreen mode

Dann löst {{token}} zu abc auf, weil Collection Variables eine höhere Priorität haben als Environment Variables.

Warum Variablen im Collection Runner verschwinden

1. Initialwert vs. aktueller Wert

Postman-Variablen haben zwei relevante Werte:

  • Initialwert: wird synchronisiert und mit Teammitgliedern geteilt
  • Aktueller Wert: bleibt lokal auf Ihrem Rechner

Wenn Sie in einem Script Folgendes ausführen:

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

setzt Postman den aktuellen Wert der Variable in der aktiven Umgebung.

Im manuellen Modus bleibt dieser aktuelle Wert in Ihrer lokalen Sitzung erhalten. Im Collection Runner hängt das Verhalten davon ab, wie der Runner konfiguriert ist und ob er Änderungen nach dem Lauf zurückschreibt.

2. Der Runner kann Variablen nach dem Lauf zurücksetzen

Im Collection Runner gibt es die Option „Variablenwerte beibehalten“.

Wenn diese Option nicht aktiviert ist, setzt Postman Umgebungsvariablen nach dem Runner-Lauf wieder auf ihren vorherigen Zustand bzw. auf Initialwerte zurück. Werte, die während des Runs gesetzt wurden, können danach im Environment Panel fehlen.

Wichtig: Innerhalb desselben Runner-Laufs können nachfolgende Requests den gesetzten Wert trotzdem verwenden. Das Problem tritt häufig erst nach Ende des Runs oder beim nächsten Run auf.

3. pm.environment.set() benötigt eine aktive Umgebung

Dieser Code schreibt in die aktive Umgebung:

pm.environment.set('token', 'abc123');
Enter fullscreen mode Exit fullscreen mode

Wenn im Runner keine Umgebung ausgewählt ist, gibt es keinen Environment-Scope, in den Postman schreiben kann.

Prüfen Sie deshalb immer vor dem Start:

  • Ist im Runner eine Umgebung ausgewählt?
  • Existiert die Variable dort?
  • Soll der Wert wirklich eine Environment Variable sein?

Wenn die Variable nur innerhalb der Collection benötigt wird, verwenden Sie besser Collection Variables.

Lösung 1: „Variablenwerte beibehalten“ im Runner aktivieren

Wenn Sie möchten, dass Variablenänderungen nach dem Runner-Lauf sichtbar bleiben:

  1. Öffnen Sie den Collection Runner.
  2. Wählen Sie Ihre Collection aus.
  3. Wählen Sie die passende Umgebung aus.
  4. Aktivieren Sie „Variablenwerte beibehalten“.
  5. Starten Sie den Run.

Danach schreibt Postman Änderungen aus dem Run zurück in die aktive Umgebung.

Verwenden Sie diese Option, wenn ein Runner-Lauf bewusst gemeinsamen Zustand aktualisieren soll, zum Beispiel ein neues Auth-Token für weitere manuelle Tests.

Vermeiden Sie sie, wenn mehrere Iterationen unabhängig voneinander laufen sollen. Sonst kann ein Wert aus Iteration 1 die folgenden Iterationen beeinflussen.

Lösung 2: Collection Variables für Werte innerhalb eines Runs verwenden

Wenn ein Token nur zwischen Requests derselben Collection benötigt wird, ist eine Collection Variable meistens robuster als eine Environment Variable.

Login-Request: Token speichern

Im Post-Response-Script des Login-Requests:

const json = pm.response.json();

pm.collectionVariables.set('token', json.access_token);
Enter fullscreen mode Exit fullscreen mode

Folge-Requests: Token lesen

Im Pre-Request-Script eines späteren Requests:

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

console.log('collection token:', token);
Enter fullscreen mode Exit fullscreen mode

Im Header können Sie dann weiterhin verwenden:

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

Collection Variables funktionieren im Runner auch dann, wenn keine Umgebung ausgewählt ist. Sie sind daher gut geeignet für Werte, die nur innerhalb einer Collection relevant sind.

Lösung 3: Vor dem Run eine Umgebung auswählen

Wenn Sie pm.environment.set() verwenden, muss im Runner eine Umgebung aktiv sein.

Checkliste vor dem Start:

  1. Collection Runner öffnen.
  2. Im Dropdown Environment eine Umgebung auswählen.
  3. Sicherstellen, dass benötigte Basiswerte vorhanden sind, z. B. baseUrl.
  4. Runner starten.

Beispiel für Environment Variables:

pm.environment.set('token', pm.response.json().access_token);
pm.environment.set('userId', pm.response.json().user.id);
Enter fullscreen mode Exit fullscreen mode

Wenn keine Umgebung ausgewählt ist, wechseln Sie entweder zu Collection Variables oder wählen Sie explizit eine Umgebung aus.

Lösung 4: Initialwerte für Pflichtvariablen setzen

Variablen wie baseUrl, clientId oder tenantId sollten nicht nur als aktueller Wert existieren.

Setzen Sie im Environment Editor:

Variable: baseUrl
Initialwert: https://api.example.com
Aktueller Wert: https://api.example.com
Enter fullscreen mode Exit fullscreen mode

Warum das wichtig ist:

  • Teammitglieder erhalten Initialwerte, aber nicht Ihre lokalen aktuellen Werte.
  • CI- oder CLI-Runs starten oft aus exportierten Initialwerten.
  • Runner- oder Newman-Läufe können leer starten, wenn nur der aktuelle Wert lokal existiert.

Für sensible Werte wie Tokens oder Secrets sollten Sie bewusst entscheiden, ob sie geteilt werden dürfen. Nicht jeder aktuelle Wert gehört in den Initialwert.

Lösung 5: Variablen mit console.log() debuggen

Wenn unklar ist, aus welchem Scope ein Wert kommt, loggen Sie beide Bereiche.

Pre-Request-Script 

console.log('collection token:', pm.collectionVariables.get('token'));
console.log('environment token:', pm.environment.get('token'));
console.log('resolved token variable:', pm.variables.get('token'));
Enter fullscreen mode Exit fullscreen mode

pm.variables.get('token') zeigt den Wert, den Postman nach der Scope-Auflösung tatsächlich verwendet.

Post-Response-Script 

const json = pm.response.json();

console.log('response access_token:', json.access_token);

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

console.log('token after set:', pm.collectionVariables.get('token'));
Enter fullscreen mode Exit fullscreen mode

Öffnen Sie vor dem Run die Postman-Konsole:

View > Show Postman Console
Enter fullscreen mode Exit fullscreen mode

So sehen Sie pro Request, wann eine Variable gesetzt, gelesen oder überschrieben wird.

Lösung 6: Newman mit Environment Export verwenden

Das gleiche Scope-Modell gilt auch für Newman.

Wenn ein Newman-Run Variablen während der Ausführung setzt, werden diese nicht automatisch in Ihre Environment-Datei zurückgeschrieben.

Beispiel:

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

Damit schreibt Newman den finalen Environment-Zustand in eine neue Datei.

Für einen Folgelauf können Sie diese Datei wieder verwenden:

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

Das ist nützlich, wenn ein Pipeline-Schritt ein Token erzeugt und ein späterer Schritt es weiterverwenden soll.

Praktisches Muster: Login einmal ausführen, Token für Folge-Requests nutzen

Für Runner-Läufe ist dieses Pattern zuverlässig:

1. Login-Request an den Anfang der Collection setzen

Der erste Request erzeugt das Token.

2. Token im Post-Response-Script speichern 

const response = pm.response.json();

if (!response.access_token) {
  throw new Error('access_token fehlt in der Login-Antwort');
}

pm.collectionVariables.set('token', response.access_token);
Enter fullscreen mode Exit fullscreen mode

3. Folge-Requests mit Header konfigurieren 

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

4. Optional im Pre-Request-Script prüfen 

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

if (!token) {
  throw new Error('token fehlt. Wurde der Login-Request vorher ausgeführt?');
}
Enter fullscreen mode Exit fullscreen mode

Damit fällt der Run früh und nachvollziehbar aus, statt später mit einem schwer einzuordnenden 401.

Wie Apidog den Variablenbereich handhabt

Apidog verwendet ebenfalls Variablenbereiche wie global, Umgebung, Sammlung und lokal. Der Unterschied liegt vor allem in der Bedienung.

Im Variablen-Editor werden Initial- und aktuelle Werte sichtbar getrennt dargestellt. Dadurch ist leichter erkennbar, welcher Wert gerade verwendet wird und welcher Wert als Startwert dient.

Apidog unterstützt außerdem Postman-kompatible Script-Aufrufe wie:

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

pm.collectionVariables.set('token', value);
pm.collectionVariables.get('token');
Enter fullscreen mode Exit fullscreen mode

Von Postman migrierte Collections können dadurch dieselbe Script-Syntax verwenden.

Wenn ein Script Variablen setzt, lässt sich der Zustand direkt im Variablenbereich nachvollziehen. Das reduziert typische Fehlkonfigurationen, bei denen ein Wert im manuellen Test vorhanden ist, im Runner aber fehlt.

Zusammenfassung häufiger Fehler

Fehler Symptom Behebung
Keine Umgebung ausgewählt pm.environment.set schreibt keinen nutzbaren Wert Umgebung auswählen oder pm.collectionVariables.set verwenden
Nur aktueller Wert gesetzt Variable fehlt bei Teammitgliedern, CI oder CLI-Runs Initialwert im Environment Editor setzen
„Variablenwerte beibehalten“ nicht aktiviert Runner-Werte sind nach dem Lauf weg Option im Runner aktivieren
Environment Variable für reinen Intralauf-Zustand verwendet Manuell funktioniert es, im Runner ist das Verhalten instabil Zu Collection Variables wechseln
Falscher Scope geprüft Variable existiert, aber Postman verwendet einen anderen Wert pm.variables.get, pm.environment.get und pm.collectionVariables.get loggen

FAQ

Warum funktioniert pm.environment.set() manuell, aber nicht im Runner?

Im manuellen Modus arbeiten Sie typischerweise in einer persistenten Umgebungssitzung. Der Runner lädt einen Ausführungskontext, führt die Requests aus und setzt Werte je nach Konfiguration nach dem Lauf zurück. Aktivieren Sie „Variablenwerte beibehalten“, wenn Änderungen nach dem Run erhalten bleiben sollen.

Was ist der Unterschied zwischen pm.environment.set() und pm.collectionVariables.set()?

pm.environment.set() schreibt in die aktive Umgebung. Diese Umgebung kann von mehreren Collections verwendet werden.

pm.collectionVariables.set() schreibt in den Scope der aktuellen Collection. Für Werte, die nur innerhalb eines Collection-Runs gebraucht werden, ist das meistens die passendere Option.

Sollte ich Tokens als Environment Variable oder Collection Variable speichern?

Für Tokens, die nur während eines Collection-Runs gebraucht werden, verwenden Sie Collection Variables:

pm.collectionVariables.set('token', pm.response.json().access_token);
Enter fullscreen mode Exit fullscreen mode

Für Tokens, die über mehrere Collections oder manuelle Tests hinweg genutzt werden sollen, können Environment Variables sinnvoll sein:

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

Tritt das Problem auch in Newman auf?

Ja. Newman verwendet dasselbe Scope-Modell. Änderungen werden nicht automatisch persistiert. Verwenden Sie --export-environment, wenn der finale Environment-Zustand gespeichert werden soll.

Was macht --export-environment in Newman?

Das Flag schreibt den finalen Zustand der Umgebung nach dem Run in eine JSON-Datei:

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

Diese Datei können Sie anschließend für weitere Runs verwenden.

Unterstützt Apidog pm.collectionVariables.set()?

Ja. Apidog unterstützt Postman-kompatible Script-APIs wie:

pm.collectionVariables.set('token', value);
pm.collectionVariables.get('token');
pm.environment.set('token', value);
pm.environment.get('token');
Enter fullscreen mode Exit fullscreen mode

Wie übergebe ich Variablen von einer Collection an eine andere?

In Postman können Sie globale Variablen verwenden:

pm.globals.set('token', value);
Enter fullscreen mode Exit fullscreen mode

Das funktioniert collection-übergreifend, sollte aber vorsichtig eingesetzt werden. Globale Variablen können schnell zu Namenskollisionen und schwer nachvollziehbarem Zustand führen.

Fazit

Wenn ein API-Test manuell funktioniert, aber im Collection Runner fehlschlägt, prüfen Sie zuerst den Variablenbereich.

Die wichtigsten Fixes sind:

  1. Für Laufzeitwerte innerhalb einer Collection pm.collectionVariables.set() verwenden.
  2. Bei pm.environment.set() immer eine Umgebung auswählen.
  3. Im Runner „Variablenwerte beibehalten“ aktivieren, wenn Änderungen nach dem Run bestehen bleiben sollen.
  4. Initialwerte für Variablen setzen, die von Anfang an verfügbar sein müssen.
  5. Mit console.log() den tatsächlich verwendeten Scope debuggen.

So vermeiden Sie falsch-negative API-Tests und machen Runner-, Newman- und Team-Ausführungen reproduzierbarer.

Top comments (0)