DEV Community

Cover image for Restrictions du Postman Collection Runner : Nouveautés et comment les contourner
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Restrictions du Postman Collection Runner : Nouveautés et comment les contourner

En bref

Postman a restreint l'accès au Collection Runner sur son offre gratuite, ce qui interrompt ou limite l'exécution automatisée des tests pour les équipes qui n'ont pas mis à niveau leur compte. Cela touche les exécutions locales, les pipelines CI/CD et les workflows qui utilisent le Runner pour lancer des requêtes en lot. Voici ce qui change, ce que cela casse concrètement, et comment exécuter les mêmes scénarios avec le runner d'Apidog sans limites d'exécution sur tous les plans.

Essayez Apidog aujourd’hui

Introduction

Le Collection Runner de Postman est souvent utilisé pour automatiser des flux API complets : exécuter une collection de requêtes, passer des variables d'une étape à l'autre, valider les réponses avec des assertions, puis récupérer un rapport d'exécution.

Exemple typique :

  1. Appeler /login
  2. Extraire un token depuis la réponse
  3. Stocker ce token dans une variable d'environnement
  4. Appeler plusieurs endpoints protégés
  5. Vérifier les statuts HTTP, les schémas JSON et les valeurs métier

Dans Postman, ce type de chaîne repose souvent sur pm.environment.set() :

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

Puis dans les requêtes suivantes :

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

Avec les restrictions introduites en 2026 sur l'offre gratuite, ces exécutions automatisées sont limitées. Les développeurs peuvent toujours envoyer des requêtes une par une, mais les exécutions groupées via le Collection Runner ou certains usages de Newman deviennent problématiques dès qu'elles sont utilisées régulièrement.

Ce que Postman a changé dans le Collection Runner

L'offre gratuite de Postman restreint désormais le Collection Runner de plusieurs façons.

Limites d'exécution mensuelles

Les comptes gratuits ont un plafond sur le nombre d'exécutions du Collection Runner par mois. Postman n'a pas publié un nombre exact de manière claire, mais des retours communautaires l'estiment autour de 25 exécutions mensuelles.

Pour une équipe qui lance une suite de tests plusieurs fois par jour, cette limite peut être atteinte très vite.

Restrictions autour de Newman CLI

Newman est l'outil CLI open-source permettant d'exécuter des collections Postman depuis un terminal ou un pipeline CI/CD.

Avant, un workflow pouvait simplement lancer :

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

Après les restrictions, certaines fonctionnalités liées à des collections synchronisées dans le cloud dépendent davantage du niveau de plan du compte Postman.

Runner visuel limité

Le Collection Runner visuel, accessible depuis l'interface Postman, peut afficher un état bloqué ou payant une fois la limite atteinte.

Ce qui reste disponible : l'envoi manuel d'une requête individuelle via le bouton Send. Les restrictions concernent surtout l'automatisation par lots.

Ce qui ne fonctionne plus bien en pratique

Tests de non-régression avant commit ou déploiement

Beaucoup d'équipes exécutent une collection avant de fusionner une pull request ou avant de déployer en staging.

Exemple :

  • 30 requêtes dans la collection de non-régression
  • 3 développeurs
  • 2 exécutions par développeur et par jour

Dans ce cas, la limite gratuite peut être consommée en quelques jours seulement.

Pipelines CI/CD

Les pipelines basés sur Newman sont particulièrement exposés.

Exemple GitHub Actions :

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

Une fois la limite atteinte, le pipeline peut échouer ou rencontrer des erreurs de quota. C'est critique si les tests API sont déclenchés à chaque push, pull request ou déploiement.

Suites API de bout en bout

Les workflows API multi-étapes utilisent souvent des variables dynamiques :

const response = pm.response.json();
pm.environment.set("user_id", response.id);
Enter fullscreen mode Exit fullscreen mode

Puis :

GET /users/{{user_id}}/orders
Enter fullscreen mode Exit fullscreen mode

Sans Runner disponible, il faut exécuter les requêtes manuellement une par une, ce qui rend les tests plus lents, moins fiables et plus difficiles à intégrer à un processus de livraison continue.

Tests de charge ou de performance basiques

Le Collection Runner permet de configurer des itérations et des délais entre requêtes. C'est utile pour des tests de charge simples, par exemple :

  • exécuter une collection 100 fois
  • ajouter un délai entre chaque itération
  • vérifier que les réponses restent stables

Avec une limite mensuelle sur les exécutions, ce cas d'usage devient peu exploitable sur l'offre gratuite.

Solutions de contournement possibles dans Postman

Si vous ne pouvez pas changer d'outil immédiatement, voici quelques options.

1. Exporter la collection et l'environnement, puis exécuter Newman localement

Vous pouvez exporter une collection Postman au format JSON et l'exécuter localement avec Newman :

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

Cette approche lit des fichiers locaux et ne dépend pas directement d'une collection synchronisée dans le cloud.

Limite : vous perdez la synchronisation automatique avec l'espace de travail Postman. À chaque modification, il faut réexporter la collection et l'environnement.

2. Découper les grandes collections

Vous pouvez diviser une collection importante en plusieurs collections plus petites.

Exemple :

api-tests-auth.json
api-tests-users.json
api-tests-orders.json
api-tests-billing.json
Enter fullscreen mode Exit fullscreen mode

Cela peut réduire la pression sur certaines exécutions, mais ce n'est pas une vraie solution. Les flux métier multi-étapes deviennent plus difficiles à maintenir, surtout si les requêtes dépendent les unes des autres.

3. Mettre à niveau uniquement le compte utilisé par la CI

Si un seul compte exécute les tests dans la CI, vous pouvez mettre à niveau uniquement ce compte, tandis que les autres membres de l'équipe restent sur l'offre gratuite.

C'est moins coûteux qu'une mise à niveau globale, mais cela ne règle pas le problème pour les développeurs qui veulent lancer les tests localement.

Comment le runner d'Apidog fonctionne différemment

Dans Apidog, le runner est disponible via les Scénarios de test ou le bouton Exécuter sur une collection. Il n'a pas de limite mensuelle d'exécution, y compris sur l'offre gratuite.

Comparaison directe :

Fonctionnalité Postman gratuit Apidog gratuit
Exécutions du Runner/mois ~25 selon des retours communautaires Illimité
Exécutions CI/CD via CLI Limité Illimité
Itérations par exécution Limité Illimité
Enchaînement de requêtes avec variables Limité Illimité
Assertions de test Disponible Disponible
Rapport récapitulatif d'exécution Disponible Disponible

Le runner CLI d'Apidog, apidog-cli, s'intègre dans une CI/CD de manière similaire à Newman :

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

Vous pouvez aussi exporter une collection depuis Apidog et l'exécuter hors ligne, comme avec Newman et un fichier local, sans dépendre de restrictions basées sur le compte.

Migrer un pipeline Newman vers Apidog CLI

Voici une transition simple dans GitHub Actions.

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

Aprè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 }}
Enter fullscreen mode Exit fullscreen mode

Les principales différences sont :

  • Apidog utilise un jeton d'accès via APIDOG_ACCESS_TOKEN
  • les exécutions référencent un projet et un environnement
  • la sortie JSON peut être utilisée pour générer des rapports ou archiver les résultats

Pour stocker le token dans GitHub Actions :

  1. Ouvrez votre repository GitHub
  2. Allez dans Settings
  3. Ouvrez Secrets and variables
  4. Ajoutez un secret nommé APIDOG_ACCESS_TOKEN
  5. Référencez-le dans le workflow avec ${{ secrets.APIDOG_ACCESS_TOKEN }}

Option alternative : continuer avec Newman

Si vous souhaitez garder Newman dans votre CI, vous pouvez exporter une collection Apidog au format JSON compatible avec Postman, puis continuer à utiliser :

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

Cette approche est utile si :

  • votre pipeline CI utilise déjà Newman
  • vous voulez éviter une migration immédiate du script CI
  • vous préférez utiliser Apidog pour concevoir et maintenir les API, tout en gardant Newman comme runner temporaire

Fonctionnalités avancées du runner Apidog

Le runner d'Apidog couvre les cas d'usage classiques du Collection Runner et ajoute plusieurs options pratiques.

Tests basés sur les données

Vous pouvez importer un fichier CSV ou JSON pour exécuter la même collection avec plusieurs jeux de données.

Exemple CSV :

email,password,expected_status
user1@example.com,password123,200
user2@example.com,badpassword,401
Enter fullscreen mode Exit fullscreen mode

Chaque ligne devient une itération de test.

Nombre d'itérations personnalisé

Vous pouvez définir un nombre précis d'itérations pour une exécution.

Exemple d'usage :

  • 10 itérations pour vérifier un flux de login
  • 100 itérations pour un test de stabilité
  • 500 itérations pour un stress test basique

Cela permet de valider rapidement la robustesse d'un endpoint sans gérer un compteur mensuel d'exécutions.

Intégration avec Smart Mock

Le runner peut interagir avec le serveur mock intégré d'Apidog. C'est utile lorsque :

  • l'API backend n'est pas encore implémentée
  • le frontend doit être testé avec des réponses stables
  • vous voulez isoler un client API d'un environnement instable

Vous pouvez donc exécuter vos scénarios contre des endpoints mockés sans lancer un serveur séparé.

Exécutions planifiées

Apidog permet aussi de planifier des exécutions automatiques :

  • toutes les heures
  • tous les jours
  • selon un calendrier défini

Les résultats sont ensuite disponibles dans l'historique de test du projet, sans avoir à configurer une tâche cron externe ou un déclencheur CI spécifique.

Conclusion

Les restrictions du Collection Runner de Postman créent un vrai blocage pour les équipes qui utilisent les tests API automatisés dans leur workflow quotidien ou leurs pipelines CI/CD.

Si vous restez dans l'écosystème Postman, les contournements possibles sont l'export local vers Newman, le découpage des collections ou la mise à niveau sélective d'un compte CI.

Si vous voulez éviter les limites d'exécution, le runner d'Apidog couvre les mêmes cas d'usage : collections, variables, assertions, itérations, exécution CLI et intégration CI/CD. La migration depuis Newman demande surtout d'adapter la commande d'exécution et de configurer un jeton d'accès dans votre pipeline.

Top comments (0)