🔧 Fork & Improve a Collection – $250 | 24 Hours Only

[gbadebo-bello]

The weekly community challenge is live! One winner gets $250 cash.

Prompt:
Fork any public collection into your own public workspace, make one improvement, and share the link. In your post, include a quick summary of what you changed.

Need ideas?

• Add or improve a test
• Clean up a request or environment
• Improve documentation for clarity
• Add an example request or response

Prize: Winner gets $250 cash (via Visa gift card)
Deadline: Thursday, Sept 25 at 10am BST / 2:30pm IST
How to enter: Reply to this thread within the 24-hour window.

This contest is open worldwide to participants 18+. By entering, you grant Postman the right to feature your submission on our website, blog, and social channels. Winner announced Friday. Go!

[danny-dainton]

This is such a cool challenge - It’s perfect for really getting hands on and exploring the publically available Collections in the Postman API Network!

---

I often like to browse the network and select Collections from companies that I’ve not heard of before, to get a better understanding about what they offer their customers.

I forked this Collection by Smartcar into my Workspace so that I could see if I could help improve it:

Initially, I can see that the documentation could be improved at the Collection level, it’s what I would see first so I’d like to know more about what the Collection offers me. There is a link out to some external documentation in Notion which is takes me away from the Collection itself, the link happens to be to a page that cannot be accessed so that could be an improvement to suggest to fix that link. That external information could be brought it the Collection documentation and fully make use of the editing features that can really make the documentation come to life!

The overall structure of the Collection and it’s Folders could also be improved, it looks like they have made a start but there are many requests that could also be grouped and renamed.

The requests could benefit from having Examples to display the type of responses that users could expect to see when calling the endpoints. This also has the added benefit of not only auto-populating that data in the documentation but those examples can also be used with a Mock Server during development.

I can see that they have some variables set, with the new Simplified Variable experience, their could add descriptions to give more context about the variable to the consumer of the API.

They have included details at the Request level for some endpoints but these could be placed directly into the request itself and using the Types feature, users would have more of an interactive view about the required params and their datatypes, it removes the guesswork.

More improvements could be made throughout this particular Collection, I was just using this as a random example.

---

I’d really love to see the type of improvements that you could all suggest, in any of the 500K+ Collections that are part of the Postman API Network!!

Get your submissions in now and get your name in the hat to win the $250 USD!!

We’re always here if you need any more help or pointers!! Good Luck!!

[satellite-meteorolo4 (Agastya Khati)]

Improved PayPal Create Order Request with Schema Validation and Example Response
I forked the official PayPal API collection and improved the Create Order request to make it more robust and developer-friendly.
Link to forked workspace : Postman

Link to the request i changed : Postman
Improvements made:

1. Response Schema Validation Test

• Added a test in the Tests (post-script) tab to validate that the response contains the expected fields: id, status, and links.
• Ensures the response structure matches PayPal’s API specification, helping developers catch changes or mistakes early.
• Example check included:

pm.test("Response matches expected schema", function () {
    pm.response.to.have.jsonSchema(schema);
});

2. Kept ID Extraction Logic

• The existing post-script extracts order_id, authorization_id, and capture_id into collection variables for use in subsequent requests.
• Ensures the collection remains fully functional for multi-step workflows.

3. Example Response

• Added a ready-to-use example of a successful Create Order response.
• Makes it easy for developers to see what a working response looks like without running the request.
• Saves time and improves readability for anyone using the collection.
  Link to example : Postman

[suraif16 (Suraif Muhammad)]

TravelTime API — Enhanced with Docs, Missing APIs, Examples, Tests & Environment

TravelTime API - Enhanced collection

I forked the official TravelTime API collection and carried out a full revamp to make it more complete and developer-friendly.

Here’s what I did:

1. Folder Descriptions → Added clear overviews for the major API groups (Isochrone, Travel Time Matrix, Routes).

2. New API Coverage → Created missing folders and requests for:

   • H3 API → /v4/h3 and /v4/h3/fast

   • Geohash API → /v4/geohash and /v4/geohash/fast

   • Distance Map API → added folder, description, and /v4/distance-map request

3. Examples for All APIs → Added examples not only to the new endpoints but also to existing ones like Isochrone, Routes, and Geocoding, so users can instantly see working responses across the board.

4. Post-response Tests Everywhere → Wrote tests for all requests (existing and new) to check status codes, JSON validity, key fields, and response time, giving immediate feedback if something isn’t configured correctly.

5. Shared Environment → Included an environment (app_id, app_key) so authentication is consistent and users can run requests straight away without editing each one.

The goal was to close the gap between the official docs and the Postman collection. With these changes, developers can fork the collection, drop in their credentials, and immediately explore all the TravelTime APIs with clear docs, examples, and tests already in place.

[hr10j44t (Uday)]

Smartcar API — Enhanced with Structure, Examples, Tests & Environment

I forked the official Smartcar API collection and fully enhanced it to make it clearer, more structured, and developer-friendly for anyone exploring the API.

---

Improvements Made:

1. Better Folder Organization

• Grouped requests into logical folders for easy navigation:

  • Auth: OAuth token, Subscribe, Unsubscribe

  • Vehicles: Vehicle details, Location, Lock/Unlock, VIN, Compatibility, Send Destination

  • Odometer: Vehicle odometer reading

  • Charging: Battery info, Charge limit, Charge status, Start/Stop charging

• Renamed requests with clear, descriptive names.

2. Example Responses for Key Endpoints

• Added ready-to-use example JSON responses for all major endpoints, including:

  • GET All Vehicles

  • GET Odometer

  • GET Location

  • POST Lock Vehicle / POST Unlock Vehicle

  • GET EV Battery Level / POST Control Charge

• This lets developers instantly see expected outputs without needing live API calls.

3. Post-response Tests (Schema & Status Validation)

• Added status code checks and JSON schema validation in the Tests tab.

• Example: validates that the Odometer response includes odometer and unit.

• Ensures developers can quickly catch mistakes or API changes.

Note: Running requests without valid credentials may return 401/404, but tests and example responses demonstrate the correct structure.

4. Variables with Descriptions

• Added detailed descriptions for base_url, access_token, client_id, and client_secret.

• Improves clarity for developers integrating Smartcar into their apps.

5. Interactive Params & Types

• Defined types for query/body parameters (string, number, boolean).

• Removes guesswork by showing exactly what inputs are expected.

6. Shared Environment

• Created a dedicated Postman environment with:

  • base_url: https://api.smartcar.com

  • client_id, client_secret, access_token

• Developers can run requests immediately by entering their credentials once.

7. Security Consideration

• For safety, I did not include any live access tokens or private API credentials in the public collection.

• Instead, placeholders and environment variables are provided so developers can securely insert their own keys.

• This keeps the fork both secure and reusable.

---

Links

• Forked Collection: Smartcar API Enhanced

• Example Request (Odometer with Example & Test): (see collection above)

• Shared Environment: Smartcar Env

---

Summary

With these enhancements, any developer can fork the collection, drop in their credentials, and immediately explore Smartcar APIs with:

• clear structure

• working examples

• validation tests

• and secure credential handling

This makes the collection beginner-friendly, production-ready, and safe to share publicly, while still supporting real-world multi-step workflows like locking a vehicle, checking battery levels, or sending a destination.

Tip for Judges:
Even if live API calls fail due to missing credentials, the examples, tests, and structure make this collection self-contained and highly educational for developers.

---

[suraif16 (Suraif Muhammad)]

BigDataCloud IP Geolocation API — Env + Pre/Post Tests

BigDataCloud IP Geolocation API - Enhanced Collection

I forked the BigDataCloud IP Geolocation API collection and made a few improvements to make it easier to run directly in Postman:

1. Shared Environment → Added variables (baseUrl, apiKey, ipAddress, localityLanguage) so all three IP Geolocation requests can be run without editing URLs manually.

2. Collection-level Pre-request Test → Added a simple check to ensure apiKey is set before sending requests, which avoids wasted calls.

3. Post-response Tests (all 3 requests) → Wrote checks for 200 OK, JSON validity, and key fields:

   • IP Geolocation → validates IP, country, and coordinates.

   • IP Geolocation with Confidence → validates IP plus confidence data.

   • IP Geolocation Full → validates presence of localityInfo and country/admin details.

With these changes, the collection is plug-and-play: paste your key once, run any of the IP Geolocation requests, and get instant feedback from the tests.

[altimetry-astronau13 (Claret)]

DocuSeal API — Enhanced Collection with Tests, Examples, Folder Organization & Developer Experience

I forked the official DocuSeal API collection and transformed it into a production-ready testing suite with comprehensive validation, organized folder structure, and developer-friendly features.

What I Enhanced:

1. Comprehensive Testing Suite (14+ Tests)

• List Submissions: 7 detailed tests (status validation, response time, JSON structure, data validation, pagination, field requirements)
• Get Submission: 7 detailed tests (status, response time, submission fields, template info, submitter validation)
• Global collection tests: Response time monitoring and error handling
• Pre-request validation: API key and environment setup checks

2. Enhanced Developer Experience

• Rich Overview documentation with 2-minute Quickstart guide
• Collection-level pre-request script that validates environment and provides helpful guidance
• Auto-population of submissionId from List Submissions to Get Submission
• Environment variables with clear descriptions (baseUrl, apiKey, submissionId)
• Console logging for debugging and status tracking

3. Organized Folder Structure with Descriptions

• Submissions Management: Core functionality for document workflows with clear use cases
• Submitters Management: Individual signer management and progress tracking
• Document Templates: Template creation, organization, and lifecycle management
• Each folder includes: Purpose, key features, common use cases, and getting started tips

4. Production-Ready Features

• Performance monitoring with response time validation (< 2s)

• Error handling with helpful debugging information

  
  
  
  
  

• One-click environment setup with clear variable descriptions

• Automatic ID chaining between related requests

Links:

• Enhanced Collection: DocuSeal API Enhanced
  Original Fork: DocuSeal API Original

[altimetry-astronau13 (Claret)]

Zendesk Support API - Enhanced Collection with Developer-Friendly Quickstart

I forked the official Zendesk Support API collection and added comprehensive Quickstart documentation to make this 500+ endpoint collection immediately usable for any developer.

What I Enhanced:

1. Rich Overview Documentation

• 2-minute Quickstart guide with step-by-step setup
• Clear environment setup (baseUrl, email, api_token, oauth_access_token)
• Authentication options (Basic Auth with API token, Bearer OAuth)
• First call verification with expected responses
• Troubleshooting section for common 401/403 errors
• Resource links to official docs and pagination guides

2. Developer Experience Improvements

• Environment variable descriptions for clarity
• Auth setup instructions to prevent common mistakes
• Error troubleshooting with specific solutions
• Professional documentation that makes the large collection approachable

3. Production-Ready Setup

• One-time configuration with clear variable setup
• Multiple auth options for different use cases
• Comprehensive error handling guidance
• Links to official resources for deeper learning

Links:

• Enhanced Collection: Zendesk Support API Enhanced

• Original Fork: Zendesk Support API Original

  

[w4dd325]

Miro REST API — Enhanced Collection

I forked the Miro REST API Postman collection and started adding some improvements.

Examples (Request + Response) - Added realrequest/response examples for the endpoints, since many users want to understand the payloads without jumping back and forth to docs.

Collection-level Pre-request Test - To ensure accessToken is set before sending any request.

Improved Documentation - Expanded descriptions in each request so users know what the endpoint does, when to use it, and what the expected response looks like. Added notes on authentication, rate limits, and common error cases to reduce confusion. I used post-bot to generate much more detailed and helpful descriptions here.

Authentication Best Practices - Instead of storing tokens directly in collection variables, I recommend using Postman Easy Auth and the Postman Vault. This keeps tokens secure, avoids accidental leaks in forks/exports, and makes it easier to rotate credentials without editing the collection.

Workflow Folders - I didn’t have time to do this, but I would also group common flows to help users see real end-to-end use cases rather than isolated endpoints.

Tests - Added tests in the Tests (post-script) tab to validate that the response contains the expected fields and the expected response codes. To do this I simply used the post-bot feature. Its so easy and saves so much time!

[abdulkabirsultan]

My Challenge Entry: Improving the Customer.io Journeys Track API Collection

I decided to fork the Customer. io Journeys Track API collection into my workspace to see how I could make it clearer, safer, and easier to use for developers.

Here’s my improved version: Journeys Track API – Improved.

---

First Impressions

When I first opened the collection, I noticed a few things right away:

• There were duplicate folders that made the collection harder to navigate.
• Some of the documentation links were broken — one even pointed to https://null.
• Request bodies were filled with placeholders like <string> and <email> that didn’t actually help me test.

These are small issues on the surface, but for someone new to the API, they can create a lot of confusion.

The original collection with duplicate folders / broken link in the Overview

---

What I Improved

Here’s what I set out to fix:

1. Fixed broken documentation links

   • Replaced the dummy EU link with clear instructions:

     Set your track_api_url variable to https://track-eu.customer.io to instantly switch all requests to EU endpoints.

   • Updated broken #operation/... links to real Postman request/folder links that open directly in the collection.

2. Cleaned up and organized folders

   • Removed redundant folders like track_v2, trackRegion, and duplicates of Customers/Events.
   • Introduced versioning to separate v1 vs v2 endpoints for clarity.
     
     
     
     improved folder structure after cleanup

3. Made request bodies developer-friendly

   • Replaced placeholders with realistic sample data (like [email protected]).
   • Used Postman Types to add schemas and data types — so instead of guessing what “” means, you can see exactly what’s required.
     
     
     
     Add or update customer request body with Types enabled

4. Added tests and scripts

   • For Find your account region, I added tests to check for a 200 OK and ensure the response contains url and region.
   • For Add or update a customer, I added a pre-request script to auto-generate a unique customer_id, removing the need to manually edit IDs.

5. Refined variable usage

   • Introduced {{customer_id}} and reused it in URLs and request bodies.
   • This means you can change the customer once and test across multiple requests without edits.

---

Why It Matters

• Developers can now trust the documentation without hitting broken links.
• Onboarding is smoother because request bodies use real examples and clear schemas.
• Testing is easier thanks to pre-request scripts and built-in validations.
• The whole collection feels more organized and professional, which reflects better on the API itself.

---

You can check out my improved fork here: Journeys Track API – Improved.

I hope these refinements make the Customer. io Track API collection a more useful resource for anyone exploring their platform!

[gbadebo-bello]

That’s a wrap!

This week’s challenge is officially closed. Thanks to everyone who shared their forks. We’re reviewing entries now.

While you wait, drop a on your favorite submissions to help us choose a winner.

Winner announced on Friday.