DEV Community

Cover image for Postman Collection Runner Einschränkungen: Was sich geändert hat und wie man sie umgeht
Emre Demir
Emre Demir

Posted on • Originally published at apidog.com

Postman Collection Runner Einschränkungen: Was sich geändert hat und wie man sie umgeht

TL;DR

Postman hat den Zugriff auf den Collection Runner im kostenlosen Tarif eingeschränkt. Dadurch können automatisierte Testläufe für Teams brechen, die den Runner für lokale Smoke-Tests, CI/CD-Pipelines oder die Massenausführung von API-Requests nutzen. Dieser Artikel zeigt, was sich geändert hat, welche Workflows betroffen sind und wie Sie dieselben Tests mit Apidogs Runner ohne Ausführungslimits umsetzen.

Teste Apidog noch heute

Einleitung

Der Postman Collection Runner war lange eine Standardfunktion für API-Tests: Sammlung auswählen, Umgebung setzen, Runner starten. Anschließend führt Postman alle Requests nacheinander aus, übergibt Variablen zwischen Schritten, prüft Assertions und erstellt einen Ergebnisbericht.

Typische Anwendungsfälle:

  • Smoke-Tests vor einem Deployment
  • Regressionstests für API-Endpunkte
  • mehrstufige Auth- und Checkout-Flows
  • CI/CD-Ausführung über Newman
  • einfache Lasttests über Iterationen und Verzögerungen

Mit den Einschränkungen von 2026 hat Postman den Zugriff auf diese automatisierte Batch-Ausführung im kostenlosen Tarif begrenzt. Einzelne Requests können weiterhin manuell gesendet werden, aber wiederholbare Collection-Läufe sind je nach Nutzung nicht mehr zuverlässig verfügbar.

Was Postman am Collection Runner geändert hat

Postmans kostenloser Tarif ist vor allem an drei Stellen eingeschränkt.

1. Monatliche Ausführungslimits

Kostenlose Konten haben ein monatliches Limit für Collection-Runner-Ausführungen. Postman hat die genaue Zahl nicht eindeutig veröffentlicht, Community-Berichte nennen jedoch ungefähr 25 Läufe pro Monat.

Für produktive Teams ist dieses Limit schnell erreicht. Beispiel:

3 Entwickler
x 2 Smoke-Test-Läufe pro Tag
= 6 Läufe pro Tag
Enter fullscreen mode Exit fullscreen mode

Bei einem Limit von etwa 25 Läufen wäre das Kontingent nach wenigen Arbeitstagen verbraucht.

2. Newman- und Cloud-Synchronisierung

Newman ist Postmans CLI-Runner für lokale und CI-Umgebungen. Früher konnten Teams exportierte Postman-Collections problemlos über Newman ausführen.

Nach den Änderungen sind bestimmte Newman-Workflows problematisch, insbesondere wenn Cloud-synchronisierte Collections und kontoabhängige Funktionen genutzt werden. Lokale Exporte funktionieren weiterhin eher als Workaround, verlieren aber die direkte Synchronisierung mit dem Postman-Workspace.

3. Visueller No-Code-Runner

Der Collection Runner in der Postman-Oberfläche zeigt nach Erreichen des Limits einen kostenpflichtigen Zustand an. Betroffen ist also nicht das manuelle Senden einzelner Requests, sondern die automatisierte Ausführung kompletter Collections.

Was in der Praxis nicht mehr zuverlässig funktioniert

Pre-Commit- und Pre-Deployment-Smoke-Tests

Viele Teams führen vor dem Merge oder Deployment eine kleine Collection aus:

Auth Request
Create Resource
Read Resource
Update Resource
Delete Resource
Logout
Enter fullscreen mode Exit fullscreen mode

Wenn diese Tests mehrmals pro Tag laufen, reicht ein kleines monatliches Runner-Limit nicht aus. Das führt dazu, dass Entwickler Tests auslassen oder manuell durchklicken müssen.

CI/CD-Pipelines

Besonders kritisch sind Newman-basierte Pipelines. Ein typischer GitHub-Actions-Schritt sieht so aus:

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

Sobald ein kontobasiertes Limit erreicht ist oder ein synchronisierter Workflow blockiert wird, kann die Pipeline fehlschlagen oder unzuverlässig werden.

Das betrifft vor allem Teams mit:

  • mehreren Branches
  • Pull-Request-Checks
  • Staging-Deployments
  • Nightly Builds
  • parallelen Pipelines

End-to-End-API-Tests

Viele Postman-Collections bilden mehrstufige API-Flows ab. Beispiel:

  1. Login ausführen
  2. Token speichern
  3. Resource erstellen
  4. Resource-ID speichern
  5. Resource aktualisieren
  6. Cleanup ausführen

In Postman wird das häufig über Variablen umgesetzt:

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

Wenn der Runner nicht verfügbar ist, müssen diese Schritte manuell nacheinander ausgeführt werden. Das ist fehleranfällig und nicht CI-tauglich.

Last- und Performance-Tests

Der Collection Runner unterstützt Iterationen und Verzögerungen. Damit lassen sich einfache Belastungstests ausführen:

Collection: api-smoke-tests
Iterations: 500
Delay: 100 ms
Enter fullscreen mode Exit fullscreen mode

Mit monatlichen Runner-Limits ist dieser Anwendungsfall im kostenlosen Tarif praktisch nicht mehr nutzbar.

Sofortige Workarounds innerhalb von Postman

Wenn Sie kurzfristig bei Postman bleiben möchten, gibt es einige Workarounds.

Workaround 1: Collection lokal exportieren und Newman offline ausführen

Exportieren Sie Collection und Environment als JSON-Dateien und führen Sie Newman lokal aus:

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

Optional mit Report-Ausgabe:

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

Vorteil:

  • funktioniert ohne direkten Runner in der Postman-UI
  • gut für lokale Tests
  • auch in CI nutzbar, wenn keine kontoabhängigen Funktionen benötigt werden

Nachteil:

  • keine automatische Synchronisierung mit dem Workspace
  • nach jeder Änderung muss neu exportiert werden
  • Versionsverwaltung der JSON-Dateien wird notwendig

Workaround 2: Große Collections aufteilen

Wenn eine Collection sehr groß ist, können Sie sie in kleinere Collections teilen:

auth-tests.json
user-tests.json
billing-tests.json
order-tests.json
Enter fullscreen mode Exit fullscreen mode

Das hilft organisatorisch, löst aber nicht das Grundproblem. Außerdem können Abhängigkeiten zwischen Requests schwieriger werden, wenn ein Flow über mehrere Collections verteilt ist.

Workaround 3: Nur CI-Konto upgraden

Wenn nur ein Service-Account oder ein Entwicklerkonto die CI-Pipeline ausführt, kann ein gezieltes Upgrade dieses Kontos günstiger sein als ein Upgrade des gesamten Teams.

Das Setup wäre dann:

Kostenlose Konten: manuelles Testen und Request-Erstellung
Bezahltes Konto: automatisierte Runner- und CI-Ausführung
Enter fullscreen mode Exit fullscreen mode

Das reduziert Kosten, macht die Pipeline aber weiterhin abhängig von Postmans Tarifmodell.

Wie Apidogs Collection Runner anders funktioniert

Apidogs Runner heißt „Test-Szenarien“ und ist auch über die Schaltfläche „Ausführen“ in Collections verfügbar. Laut ursprünglicher Funktionsbeschreibung gibt es keine monatlichen Ausführungslimits in den Tarifen, einschließlich des kostenlosen Tarifs.

Dokumentation: Test-Szenarien in Apidog erstellen

Funktion Postman kostenlos Apidog kostenlos
Runner-Ausführungen pro Monat ~25 laut Community-Berichten Unbegrenzt
CI/CD-Läufe per CLI Begrenzt Unbegrenzt
Iterationen pro Lauf Begrenzt Unbegrenzt
Request-Verkettung mit Variablen Begrenzt Unbegrenzt
Test-Assertions Verfügbar Verfügbar
Zusammenfassender Ausführungsbericht Verfügbar Verfügbar

Der wichtigste Unterschied für Entwickler: Automatisierte Tests bleiben ein normaler Bestandteil des Workflows, statt ein Verbrauchskontingent zu sein.

Apidog Runner lokal oder in CI ausführen

Der Apidog CLI-Runner (apidog-cli) lässt sich ähnlich wie Newman in lokale Skripte und CI/CD-Pipelines integrieren.

Allgemeines Muster:

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

Mit Ausgabe in eine Ergebnisdatei:

apidog run --project {project-id} \
  --env {env-id} \
  --output results.json
Enter fullscreen mode Exit fullscreen mode

Die Authentifizierung erfolgt über ein Access Token, das Sie in CI als Secret speichern sollten.

Migration von Newman zu Apidog CLI in GitHub Actions

Vorher: 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

Nachher: 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

Die wichtigsten Änderungen:

  • Newman nutzt lokale Collection- und Environment-Dateien.
  • Apidog referenziert Projekt und Umgebung.
  • Das Access Token wird über APIDOG_ACCESS_TOKEN bereitgestellt.
  • JSON-Ausgaben können weiterhin für Reporting oder Artefakte genutzt werden.

Optional können Sie die Ergebnisdatei als GitHub-Actions-Artefakt speichern:

- name: Upload API test results
  uses: actions/upload-artifact@v4
  with:
    name: api-test-results
    path: results.json
Enter fullscreen mode Exit fullscreen mode

Lokaler Testlauf mit Apidog CLI

Für lokale Tests können Entwickler denselben Befehl ausführen:

export APIDOG_ACCESS_TOKEN="your-token"

apidog run --project {project-id} \
  --env {env-id} \
  --output results.json
Enter fullscreen mode Exit fullscreen mode

So lässt sich vor einem Commit prüfen, ob die API-Flows funktionieren:

npm install -g apidog-cli
apidog run --project {project-id} --env {env-id}
Enter fullscreen mode Exit fullscreen mode

Wenn der Befehl fehlschlägt, kann der Commit oder das Deployment gestoppt werden.

Bestehende Newman-Workflows weiterverwenden

Wenn Sie Newman weiterhin nutzen möchten, können Sie eine Apidog-Collection als Postman-kompatible JSON exportieren und lokal ausführen:

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

Das ist sinnvoll, wenn:

  • bestehende CI-Skripte vorerst unverändert bleiben sollen
  • Ihr Team Newman-Reporter nutzt
  • Sie schrittweise migrieren möchten

Langfristig ist der direkte CLI-Lauf mit Apidog einfacher, weil Sie nicht nach jeder Änderung neue JSON-Dateien exportieren müssen.

Mehrstufige API-Flows in Apidog abbilden

Ein typisches Testszenario besteht aus mehreren Requests, die Daten weitergeben:

1. POST /login
2. Token speichern
3. POST /orders
4. Order-ID speichern
5. GET /orders/{id}
6. Response validieren
7. DELETE /orders/{id}
Enter fullscreen mode Exit fullscreen mode

In solchen Flows sind Variablen entscheidend. Das Grundprinzip bleibt ähnlich wie bei Postman:

Response aus Request A -> Variable speichern -> Request B verwendet Variable
Enter fullscreen mode Exit fullscreen mode

Damit können Sie reale API-Abläufe automatisiert ausführen, statt einzelne Requests manuell zu testen.

Datengesteuerte Tests

Apidog unterstützt datengesteuerte Testläufe mit CSV- oder JSON-Daten. Dadurch können Sie dieselbe Collection mit mehreren Datensätzen ausführen.

Beispiel als CSV:

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

Ein Testlauf wird dann pro Zeile ausgeführt. Das ist praktisch für:

  • Login-Tests
  • Rollen- und Berechtigungstests
  • Validierung verschiedener Payloads
  • Boundary-Tests
  • Regressionstests mit Testdatensätzen

Iterationen für einfache Stresstests

Wenn Sie eine Collection mehrfach ausführen möchten, können Sie Iterationen verwenden.

Beispiel:

Collection: checkout-flow
Iterations: 500
Environment: staging
Enter fullscreen mode Exit fullscreen mode

Das ersetzt kein spezialisiertes Lasttest-Tool, reicht aber für einfache Stabilitätsprüfungen:

  • Bleiben Responses konsistent?
  • Gibt es sporadische 500er?
  • Funktionieren Tokens und Sessions über mehrere Läufe?
  • Gibt es offensichtliche Timeouts?

Mock-Server in Testläufe einbinden

Apidogs Runner kann mit dem integrierten Mock-Server genutzt werden. Das ist hilfreich, wenn ein Backend noch nicht vollständig implementiert ist.

Beispiel-Workflow:

Frontend oder Client-Code -> Mock API
Test-Szenario -> Mock-Endpunkte
Assertions -> erwartete Response-Struktur prüfen
Enter fullscreen mode Exit fullscreen mode

So können Teams API-Verträge testen, bevor alle Services produktionsbereit sind.

Geplante Testläufe

Apidog unterstützt geplante Läufe, z. B.:

stündlich
täglich
wöchentlich
Enter fullscreen mode Exit fullscreen mode

Das ist nützlich für kontinuierliche Checks außerhalb der CI-Pipeline:

  • Staging-API jede Stunde prüfen
  • Produktionsnahe Smoke-Tests täglich ausführen
  • Regressionstests vor Arbeitsbeginn laufen lassen
  • Ergebnisse in der Projekthistorie nachvollziehen

Damit benötigen Sie nicht zwingend externe Cron-Jobs oder zusätzliche CI-Trigger.

Empfohlener Migrationsplan

Wenn Ihr Team aktuell Postman und Newman nutzt, ist eine schrittweise Migration am risikoärmsten.

Schritt 1: Kritische Collections identifizieren

Listen Sie zuerst die Collections auf, die automatisiert ausgeführt werden:

api-smoke-tests
auth-regression-tests
checkout-e2e-tests
billing-api-tests
Enter fullscreen mode Exit fullscreen mode

Priorisieren Sie Collections, die in CI/CD laufen oder Deployments blockieren.

Schritt 2: Collection nach Apidog übernehmen

Übertragen oder importieren Sie die relevanten API-Requests und Umgebungen in Apidog. Prüfen Sie danach:

  • Base URL
  • Header
  • Auth-Konfiguration
  • Environment-Variablen
  • Pre-Request-Logik
  • Test-Assertions

Schritt 3: Test-Szenario erstellen

Bilden Sie den bisherigen Collection-Runner-Flow als Test-Szenario ab:

Login
Create resource
Validate resource
Update resource
Delete resource
Logout
Enter fullscreen mode Exit fullscreen mode

Achten Sie darauf, dass Variablen zwischen Requests korrekt gesetzt und gelesen werden.

Schritt 4: Lokal ausführen

Führen Sie das Szenario lokal aus:

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

Beheben Sie fehlende Variablen, Auth-Probleme oder Assertion-Fehler, bevor Sie die CI-Pipeline ändern.

Schritt 5: CI-Pipeline aktualisieren

Ersetzen Sie Newman durch 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

Schritt 6: Ergebnisse versionieren oder archivieren

Speichern Sie Reports als Artefakte:

- name: Upload API test results
  uses: actions/upload-artifact@v4
  with:
    name: api-test-results
    path: results.json
Enter fullscreen mode Exit fullscreen mode

So bleiben Testergebnisse nachvollziehbar.

Fazit

Postmans Einschränkungen beim Collection Runner treffen vor allem Teams, die automatisierte API-Tests im kostenlosen Tarif aufgebaut haben. Betroffen sind lokale Smoke-Tests, Newman-basierte CI/CD-Pipelines, mehrstufige API-Flows und einfache Iterations- oder Lasttests.

Kurzfristig können lokale Newman-Exporte helfen. Langfristig ist ein Runner ohne monatliche Ausführungslimits stabiler für Entwicklungs- und CI-Workflows. Apidogs Runner deckt die typischen Collection-Runner-Anwendungsfälle ab und lässt sich mit apidog-cli in bestehende Pipelines integrieren.

Top comments (0)