🔄 Automate the Repetitive – $150 | 24 Hours Only

Show and Tell
,
22

Automatically Clear/Reset Environment Variables After Test Runs

The Problem:
Every Postman user who runs collections regularly faces the same hidden productivity killer: environment variable pollution. After each test run, variables like userId, authToken, orderId, etc. persist in the environment, creating a cascade of issues that compound over time.

Why This Matters More Than You Think:

  • Silent Failures: Old variables cause mysterious test failures and false positives that can waste hours of debugging
  • Team Friction: One developer’s leftover variables confuse teammates and break shared environments
  • Cognitive Overhead: The constant mental burden of remembering to manually clean up after every run
  • Scales Badly: The problem gets exponentially worse in CI/CD pipelines and automated testing

The Solution:
Add a “Clean Environment After Run” option that automatically:

  • Resets specified variables to default values
  • Clears all variables created during the collection run
  • Logs cleanup actions for traceability
  • Works seamlessly with Collection Runner and Newman

Impact:
This isn’t just a nice-to-have—it’s infrastructure that makes Postman more reliable for everyone. While other features might speed up specific workflows, this prevents the kind of silent breakage that undermines trust in your testing process.

Every Postman user who’s ever wondered “why is this test suddenly failing?” or spent time hunting down stale variables will immediately appreciate this improvement.

23

The repetitive pain:
I often start by testing endpoints with concrete values (UUIDs, emails, numeric IDs) in the URL, query, headers, and body. Later, I have to manually replace those literals with variables, create defaults, wire up pre-request generators, and add tests to capture IDs for chaining. Doing this across a folder/collection is tedious and error-prone.

How Postman could help:

  • Detect literals and patterns in a request (UUIDs, emails, timestamps, tokens, numeric IDs) and suggest variable replacements based on field names (e.g., userId → {{user_id}}).
  • Offer a “Parameterize request” quick action (and bulk mode for a folder/collection) that:
    • Replaces detected literals with variables.
    • Creates environment/local variables with sensible defaults or generation strategies (uuid(), faker.email, now()+offset).
    • Adds optional pre-request scripts to generate dynamic values.
    • Adds optional test snippets to extract IDs from responses for request chaining.
    • Shows a dry-run diff and lets me approve per replacement.
  • Smart mapping:
    • Reuse existing variables if names match.
    • Infer from OpenAPI/collection schema when available to propose better variable names and types.
24

Automatic VPN Connection and Configurable VPN Zone Setting.

Whenever I test APIs that are regionally blocked I need to connect to the VPN and manually change the VPN zone for that specific API call. I would love to have a feature that allows me to configure the zone for the API and Postman connecting me to that specific VPN zone automatically.

25

Request Variations Feature to Avoid Manual Duplication

:light_bulb: Idea Summary

Postman should include a built-in feature that allows users to define and run multiple input variations for a single request. This would remove the need to manually duplicate requests when testing different payloads, headers, or query parameters.

:cross_mark: The Problem

When testing an API endpoint — like POST /create-user — developers and testers often want to test multiple scenarios:

:white_check_mark: Valid inputs

:cross_mark: Missing required fields

:cross_mark: Invalid data types

:warning: Boundary values (e.g. max string length)

:locked: Unauthorized or expired tokens

Even though most well-designed APIs have backend validation that throws the appropriate errors (e.g. 400 Bad Request, 422 Unprocessable Entity, 401 Unauthorized), developers and testers still need to:

  1. Manually create requests to test each of these scenarios

  2. Duplicate the base request and tweak inputs for each test

  3. Check that the correct error/status code and message is returned

This leads to repetitive manual work, cluttered collections, and more time spent on test setup than actual testing.

:white_check_mark: Suggested Solution

Introduce a "Request Variations" feature in Postman that allows users to:

Define multiple payload variations within a single request

Add tags/labels to describe the variation (e.g. “missing email”, “invalid age”)

Optionally modify headers, params, or authentication per variation

Run all variations at once

View results in a grouped format showing input, status, and response

Export/import variations for reuse across projects or teams

This is similar to data-driven testing, but natively integrated into Postman’s UI, without requiring CSV files or Collection Runner configuration.

:brain: Why It Matters

:white_check_mark: Backend validation still needs to be tested — this makes it faster and easier

:white_check_mark: Reduces time spent manually duplicating and editing requests

:white_check_mark: Keeps collections clean and maintainable

:white_check_mark: Helps testers cover edge cases and negative tests efficiently

:white_check_mark: Encourages better documentation of test scenarios

:white_check_mark: Supports a more robust and streamlined API testing workflow, especially in teams

26

The Problem: Postman’s Import/Export Limitations

The problem stems from Postman’s handling of collections with multiple folders during import and export. When a user exports a collection that contains numerous folders, all the folders and their requests are consolidated into a single JSON file. This monolithic structure becomes a significant pain point when trying to manage and integrate the collection with a GitHub repository for version control and collaborative development.

The Pain Points

The core issue is that Postman’s import/export functionality does not provide an option to automatically split the collection’s folders into individual files. This creates a few specific pain points:

  • Version Control Challenges: When multiple developers work on different folders within the same collection, any change, no matter how small, requires exporting the entire collection as one large JSON file. GitHub, which tracks changes on a file-by-file basis, sees this as a massive single-file update. This makes it incredibly difficult to review pull requests, identify specific changes, and merge conflicts. The granular tracking of changes that Git provides is lost.

  • Manual Work and Repetitive Tasks: To overcome this, developers are forced to write and maintain custom scripts. These scripts are needed to parse the single exported JSON file and split it into separate files—one for each folder or even each request. This is a time-consuming and error-prone process that must be repeated every time a change is made.

  • Collaboration Inefficiency: The lack of a native “split by folder” feature hinders a smooth collaborative workflow. A developer might finish their work on one folder but cannot easily push just their changes to the repository. Instead, they must run a script, which might affect other parts of the collection, leading to potential conflicts and confusion among team members. This manual overhead slows down development cycles and reduces productivity.

This manual process of “splitting” the collection by folder is a significant inefficiency, essentially negating the benefits of using Postman for team collaboration and the power of Git for version control.

27

One small but repetitive task I’d love Postman to take off my plate:

Managing workspace clutter. Over time, collections, environments, and tests pile up. I don’t want to delete them (they might be useful later), but manually organizing them is repetitive and time-consuming.

I’d love an Archiving feature with:

  • Auto-archiving of unused collections/environments after a set period (with easy restore).

  • Notification for reminder that a collection has not been used for more than 60 days, Collection will be auto archived within 15 days. (Don’t Archive/Dismiss).

  • Manual-archiving for admins to preserve legacy APIs and documention.

  • Read-only mode for archived items so they’re preserved but not editable.

  • Role-based archival controls so admins can decide what gets archived while collaborators can only view or comment.

  • Auto-collapse in the sidebar so archived collections don’t distract from active work.

  • Role-specific comments/annotations on archived collections, so teams can explain why something was archived or how it could be reused later.

That way, workspaces stay clean, but knowledge and history are never lost.

28

Request Data Refresher - Automate Expired Test Data So You Can Focus on Building

The Problem:

I’ve lost track of how many times I’ve run into failed requests because tokens expired mid-test or resource IDs became invalid. Every time I switch environments, refresh credentials or test across sandboxes, I spend minutes searching for valid data, copying it and updating requests manually. It’s a repetitive grind that breaks focus and slows down testing especially when deadlines are tight and teams need to iterate fast.

Why It Matters:

Outdated test data doesn’t just cause failed requests it leads to misleading errors, wasted time and unnecessary debugging. Even experienced teams lose momentum when tests fall apart because of stale tokens or missing references. When you’re juggling multiple environments or running tests in quick succession, this “hunt-and-update” cycle becomes a productivity drain that no one talks about but everyone feels.

The Solution:

Request Data Refresher Agent a background assistant that keeps your test data fresh, so you never have to scramble before hitting “Send.”

How It Works:

  1. Detect Outdated Data
    The agent scans requests and recent responses to spot expired or invalid values using patterns like:
    • “access_token expired”
    • “invalid resource ID”
    • “not found” or “missing parameter”
  2. Auto-Fetch Fresh Values
    • For OAuth or API keys — it runs refresh flows and updates environment variables instantly.
    • For resource IDs — it fetches the latest data from relevant endpoints (e.g., GET requests for available records) and inserts them into requests automatically.
  3. Batch Update Across Requests
    • A one-click refresh updates all affected requests, avoiding tedious copy-paste work and reducing errors.
  4. Notify and Guide
    • After each run, it shows a summary: what was updated, links to new requests, and flags any manual steps needed (e.g., permissions or scope changes).

Value:

This agent transforms routine test prep into an effortless background process.
:white_check_mark: Save hours of manual setup every week
:white_check_mark: Eliminate false failures caused by stale data
:white_check_mark: Streamline workflows across teams and environments
:white_check_mark: Focus on building, testing, and shipping without interruptions

With Postman handling the grunt work, developers can finally focus on what really matters building reliable APIs with confidence.

Testing APIs should be about validating functionality not chasing expired tokens or hunting for IDs. The Request Data Refresher Agent turns frustration into efficiency, helping teams stay productive without second-guessing test setups. It’s the little automation every API developer dreams of but never had until now.

Notebook: Postman

29

One small but repetitive task I’d love Postman to take off my plate:

Every day, I have to manually run the same set of API requests across different environments (dev, staging, production) just to check if the basic stuff is working. I open Postman, switch environments, send requests one by one, and check the responses.

It would be awesome if Postman could let me set up a simple “Environment Health Check” where I can pick a few important requests, choose environments, and schedule it to run automatically (like every morning at 9 AM). Then it could send me a report if something’s wrong (like a failed status code or wrong response format).

That way, I don’t have to waste time doing this manually every day and can catch issues fpaster.

1 Like
30

Problem: Saving Postman collections with Git requires repetitive, manual file exports.

Solution: Save collections as code files, letting Git track changes automatically

1 Like
31

“Stop making me rebuild auth tokens every single restart!”

Every Postman restart = 15 minutes rebuilding tokens across 6 environments. Laptop updates overnight? Gone. Session expires during lunch? Gone again. My “2-minute API test” becomes a 20-minute authentication marathon.

This isn’t just my pain - it’s everywhere:

Current workarounds suck:

  • Put tokens in Initial Values → teammates see my secrets :prohibited:

  • Use Postman Vault → too much setup friction for daily workflow :prohibited:

  • Keep rebuilding Current Values → soul-crushingly repetitive :prohibited:

What I desperately need: Smart Current Values that persist locally for 24 hours and survive restarts. Not synced, not permanent - just cached locally so I don’t lose my flow.

Impact: Save 3+ hours weekly. End the most demoralizing workflow killer in Postman.

One simple toggle. Massive productivity gain. Let’s make it happen.

25 Likes
32

Auto-Refresh Stale API Tokens Across Collections
Manually updating expired auth tokens (OAuth, Bearer, etc.) across multiple Postman collections or environments is a repetitive pain—especially during active development or testing.
For this I want Postman to

  • Detect when a token is expired or nearing expiry.

  • Auto-trigger a refresh flow using stored credentials or refresh tokens.

  • Propagate the new token across all linked collections/environments.

This would save hours of manual updates, reduce failed requests, and streamline workflows for developers juggling multiple APIs

1 Like
33

Smart auto-refresh of expired auth tokens

Currently, when working with OAuth or JWT tokens that expire mid-testing session, I have to:

  1. Notice my requests are failing with 401s

  2. Stop what I’m doing

  3. Go back to the auth endpoint

  4. Re-authenticate

  5. Copy the new token

  6. Update it in my environment variables

  7. Resume testing

It would be incredible if Postman could detect auth failures, automatically retry the token refresh endpoint (that I’ve configured once), update the environment variable with the fresh token, and seamlessly retry my original request all without me having to context-switch.

This happens multiple times per day when working with microservices or during long debugging sessions. The interruption kills flow state and the manual token juggling is pure busy work that adds zero value to actual API testing.

Just set up the refresh logic once, then never think about expired tokens again while focusing on what actually matters, testing the API functionality.

34

I developed a script for this and it has help me alot.

35

I’d love Postman to automatically generate and maintain API documentation that stays in sync with my actual requests and responses.

Right now, I find myself constantly updating documentation after making changes to endpoints, request parameters, or response structures. It’s tedious to manually edit descriptions, update example payloads, and ensure the documentation reflects the current state of the API.

Imagine if Postman could watch my collection runs and automatically detect when request/response schemas change, then prompt me to update the documentation or even suggest updates based on the actual data flowing through. It could maintain a living changelog of API changes and keep examples fresh without me having to remember to manually sync everything after each modification.

This would save developers hours of documentation maintenance while ensuring API docs never go stale.

36

I’m not sure if this is a small thing or a big one. Right now, I’m working with an API that gets updated every week on Swagger. I don’t know if Postman can automatically detect when new endpoints are added and include them in the collection, maybe by checking the base URL. Honestly, whenever there’s an update, I usually either delete the old collection or go through Swagger again to find the new endpoints.

37

I’d love Postman to automatically pause and resume requests based on API rate limit headers, then send me a subtle notification when it’s safe to continue.

Right now, when I’m doing exploratory API testing or debugging a sequence of calls, I constantly hit rate limits and have to manually calculate wait times from the X-RateLimit-Reset headers, set timers on my phone, or just guess when to try again. It breaks my flow completely.

What would be magical is if Postman could intercept 429 responses, parse the rate limit headers (like Retry-After or X-RateLimit-Reset), and automatically queue my next request to fire exactly when the rate limit window resets. It could show a tiny countdown timer in the corner and maybe send a gentle desktop notification when it’s about to resume.

This would let me chain together a bunch of requests for testing without babysitting the rate limits, and I could go grab coffee or work on something else instead of staring at headers doing mental math about Unix timestamps. Perfect for those APIs with strict limits where you need to test multiple scenarios but don’t want to get blocked or waste time waiting around.

38

Automated Workflow Notifications

Problem:

When a scheduled collection run finishes, I manually check results and then notify my team via Slack/Email. This gets repetitive.

Solution:

Postman could send smart notifications to collaboration tools (Slack, Teams, Email) with highlights like failures, performance issues, or environment changes.

How it Works:

1. User configures notification channels (Slack, Teams, Email).

2. Postman auto-generates a summary after each run.

3. Summary includes key details (passed/failed requests, average response time, environment used).

4. Notifications are sent instantly without manual reporting.

39

Here’s what annoys me: An API that was working fine yesterday suddenly returns slightly different data today. Maybe a field got renamed from user_id to userId, or an array that used to return 10 items now caps at 5, or timestamps switched from Unix to ISO format. The backend team “forgot” to mention it, and now I’m debugging phantom failures.

What I desperately need is Postman to remember the “shape” of successful responses and automatically flag structural changes. Not just status codes but even the actual response anatomy.

For example: Every time I get a 200 OK, Postman quietly fingerprints the response structure. Next time I run the same request, it compares:

  • Did any fields disappear or get renamed?

  • Did data types change? (string → number, object → array)

  • Did array lengths drastically change?

  • Did nested structure shift?

When something changes, instead of a cryptic test failure, I should get: “Hey, this endpoint’s response structure changed since last Tuesday. Field ‘created_at’ is now ‘createdAt’ and the ‘metadata’ object moved inside ‘data’.”

This would turn hours of “why is this broken now?” into seconds of “oh, they changed the API again.”

40

Manually creating realistic dummy payloads for API testing is repetitive. Since Postman already has access to schemas via OpenAPI imports, saved examples, or response structures, it could auto-generate test data (emails, IDs, timestamps, nested objects) with one click. This would save hours, improve testing speed, and help both beginners and advanced teams stay inside Postman.

41

i like to a make Postman to automate is this whole guessing about how API updates might mess things up for current users. if Postman could safely replay real recent API calls with the new version before we actually roll it out? Then it could tell us exactly where things break or don’t match.

This would save so much time from manually checking everything, reduce rollbacks, and just help teams feel more confident making changes without accidentally breaking other apps that depend on that Api