Best Postman collection generation tools for developer testing (September 2026)

Converting an OpenAPI document into a Postman collection is a solved problem. Postman open sourced the converter it uses for its own import, the same library ships on npm, and every competing API client reads the format. What is not solved is the part teams actually care about: a converted collection is a list of requests with no assertions, no chained state, and no failure condition, so running all of it against a live API proves only that the endpoints exist. The decision axis for choosing among these tools is therefore not conversion fidelity but the test layer: whether a tool stops at requests, generates assertions from the schema, or runs the result in CI with an exit code. This comparison evaluates the API tooling in that order, because the import step is commodity and the testing step is where the tools genuinely differ.

TLDR:

• Conversion is commodity. openapi-to-postmanv2 is the converter behind Postman's own import, it is open source, and it handles Swagger 2.0, OpenAPI 3.0, and 3.1.
• A generated collection contains requests, not tests. Portman is the tool that closes that gap, generating contract, variation, and fuzzing tests from the schema and running them through Newman.
• Collection quality is bounded by spec quality. operationId, tags, examples, securitySchemes, and servers map directly onto request names, folders, saved examples, auth, and variables.
• Postman's two-way sync keeps a collection aligned with its spec, but it does not support multi-file OpenAPI documents and leaves orphan requests behind unless the removal setting is enabled.
• Kong Insomnia and Bruno read the same specs and run in CI, and Bruno stores collections as plain-text files in git, which makes collection changes reviewable in a pull request.
• Fern's own Postman collection generator is no longer maintained, and the documented path is importing the spec into Postman. Fern's role in this workflow is upstream, keeping the API definition validated and example-rich, and downstream, generating a documentation site from a Postman collection.

What Postman collection generation tools actually do

A Postman collection is a JSON document in Postman's Collection format describing requests, folders, variables, auth, and scripts. Generating one means mapping an API definition onto that structure, and the mapping is mechanical rather than interpretive.

Everything a test needs sits outside that table. Assertions, environment setup, values carried from one response into the next request, and a pass or fail signal are scripts and configuration, not schema fields. Tools in this category divide cleanly by how much of that gap they close on their own.

Why teams generate collections instead of maintaining them by hand

Hand-maintained collections fail in one specific way: someone ships an endpoint, nobody adds the matching request, and two releases later the collection describes an API that no longer exists. Developers who trust it hit a 404 and file a support ticket. The case for generation is that it makes the collection a build artifact of the spec rather than a document a person owns.

• Coverage is guaranteed by construction. Every operation in the spec produces a request. There is no path where a new endpoint silently lacks one.
• Auth and base URLs stay correct. Security schemes and servers regenerate with the spec, so credential setup does not rot independently of the API.
• The collection becomes reviewable. When generation runs in CI, a spec change and its collection consequence land in the same pull request.
• Onboarding improves measurably. A collection is often the first thing a developer opens, and a generated one reflects the API as shipped rather than as it was six months ago.
• Testing gets a substrate. Contract tests and smoke suites need a request inventory to attach to, and generation produces that inventory for free.

The cost is that generation amplifies whatever is wrong with the spec. A vague, example-free OpenAPI document produces a collection of unnamed requests with empty bodies, which is worse than nothing because it looks official.

What makes a strong Postman collection generation tool in 2026?

The tools below were evaluated against the criteria that determine whether a generated collection is usable for testing rather than merely importable.

• Spec version coverage: Swagger 2.0, OpenAPI 3.0, and 3.1 at minimum, since most API programs still carry a mix.
• Test generation: whether the tool emits assertions derived from the response schema, or only requests.
• CI operation: whether generation and execution run headless with a non-zero exit code on failure, without a human in a GUI.
• Naming and folder control: whether request names and folder strategy are configurable, because defaults produce collections organized by URL rather than by concept.
• Sync behavior: what happens on the second run, and whether regeneration preserves or destroys hand-added scripts and variables.
• Auth handling: whether OAuth 2.0, bearer tokens, and API keys carry across from the spec's security schemes into working collection auth.
• Version control: whether the generated artifact is diffable in git, or lives only in a hosted workspace.

Fern

Fern is not a Postman collection generator, and being precise about that is more useful than stretching the category. Fern's older Postman collection generator is no longer actively maintained, and the documented path is importing the OpenAPI specification into Postman directly.

Fern sits on both sides of that import. Upstream, it is the layer that produces and validates the API definition the collection is generated from, working with OpenAPI, AsyncAPI, OpenRPC, gRPC, and its own Fern Definition, and carrying request and response examples through to generated output. Since collection quality is bounded by spec quality, that is where most of the leverage in this workflow actually is. Downstream, Fern's Postman integration runs in the other direction: it generates a documentation site from an existing Postman collection, producing an API reference with request details, sample code, and an interactive API Explorer, with guides and branding alongside it. Fern is a Postman company, and its own generation focus is SDKs in nine languages rather than collections, which covers the integration path a collection is not meant to serve.

Postman native import and Spec Hub

Postman's built-in import is the default answer and the right one for most teams. Spec Hub imports OpenAPI, AsyncAPI, protobuf, GraphQL, and Smithy specifications, and generates a collection from a specification inside the workspace with no external tooling. That format breadth is a reason to start here rather than with a converter, since the standalone converters in this comparison read OpenAPI only.

The capability that distinguishes it is two-way sync between a spec and its generated collection in Spec Hub: spec updates push into the collection, and collection edits can flow back. Two limitations matter in practice and are documented by Postman. Syncing to multi-file OpenAPI specifications is not supported, so a spec split across $ref-linked files has to be bundled into a single document first, which is a real constraint for large API programs. And renaming a path creates a new request while the old one remains, unless the "Remove orphan requests" setting is enabled. Left off, a synced collection accumulates requests for endpoints that no longer exist, which is the exact failure generation was supposed to prevent.

openapi-to-postmanv2

openapi-to-postmanv2 is the converter Postman built for its own import and open sourced. It is on npm as both a library and a CLI, and it is the correct choice when conversion needs to happen in a script rather than a GUI.

Its value over the app is control over the output shape. folderStrategy organizes requests by tag or by path, and requestNameSource chooses between the URL and a fallback chain of description, then operationId, then URL. A representative invocation:

openapi2postmanv2 -s openapi.yml -o collection.json -p \
  -O folderStrategy=Tags,requestNameSource=Fallback,includeAuthInfoInExample=false

Those two options account for most of the difference between a collection developers navigate comfortably and one organized by raw URL. What the converter does not do is merge: each run produces a fresh collection file, so hand-added scripts and variables are not carried forward. That makes it a good fit for a pipeline that treats the collection as fully generated, and a poor one for a collection people also edit by hand.

Portman

Portman is the tool that addresses the gap this comparison turns on. Maintained by Apideck, it converts an OpenAPI 3.0 or 3.1 specification into a Postman collection and injects a test suite, then optionally uploads the collection to Postman or runs it through Newman.

The generated suites fall into recognizable categories. Contract tests are the happy path, one request per operation built from the headers, parameters, and request body the spec marks as required, asserting a successful response. Variation tests cover alternate paths and error conditions for the same operation. Portman also supports fuzzing, pre-request scripts, and per-request customization through a configuration file, so generated assertions can be extended without hand-editing the collection.

This is the difference between a collection that documents an API and one that can fail a build. For teams whose goal is contract verification in a pipeline rather than a browsable request library, Portman is the strongest fit in this list, and it composes with everything else here because its output is an ordinary collection.

Postman CLI and Newman

Generation produces an artifact; something has to run it. Two runners are supported, and Postman's own comparison is direct about how they differ. The Postman CLI, released in September 2022, is digitally signed by Postman, supports logging in from the command line and storing an API key locally, can execute a subset of a collection by request or folder ID with -i, and reports run results back into the Postman app. New integrations land there first.

Newman is not going away. Postman states there are no plans to deprecate it, and it remains the pragmatic choice when the collection is a file in the repository rather than a cloud resource, since it takes a path or URL and needs no workspace binding. It installs through npm or Homebrew, it is open source with roughly a hundred community contributors, and it is not digitally signed by Postman, which is worth knowing if CI artifacts go through a signature check. Both return a non-zero exit code on assertion failure, which is the only property a CI gate strictly requires.

Kong Insomnia and Inso CLI

Insomnia imports OpenAPI specifications and generates runnable collections, and it covers REST, GraphQL, gRPC, WebSockets, and Server-Sent Events, which is broader protocol coverage than a Postman collection expresses.

Its CI story is Inso CLI, which lints specs, runs collections with inso run collection, and runs unit tests with inso run test, returning a non-zero exit code when tests fail. The workflow Kong documents is the one that matters here: design the spec, share it, then generate a test collection from the same spec so tests and contract stay attached. Insomnia is the right evaluation when the API program includes non-REST protocols or when Kong is already in the stack. It is the wrong one if collections need to be shared with external developers who expect a Postman collection, since that means an export step on every change.

Bruno

Bruno takes the opposite architectural position from a hosted workspace. Collections are plain-text .bru files on the filesystem, so they are versioned in git alongside the spec and the service code, reviewed in pull requests, and diffable.

Generation is a CLI operation: bru import openapi --source api.yml --output ./collection --collection-name "My API" produces a collection directory from a local file or a remote URL, and recent versions carry info.description, tag descriptions, and per-request descriptions into the docs tab. The @usebruno/cli package runs collections in CI the same way Newman does.

For teams that already treat the collection as a build artifact, git-native storage removes the whole class of problems caused by a hosted workspace drifting from the repository. The tradeoff is ecosystem: Postman collections are the interchange format developers expect, and Bruno's format is not that, so an external-facing collection still needs to be produced in Postman's format separately.

Feature comparison table of Postman collection generation tools

The second column is the one that separates these tools. Every row that says "No" is a tool that produces a request inventory and leaves the testing problem entirely to whatever runs next.

What a generated collection cannot test on its own

A converted collection asserts nothing. Running it end to end against a live API returns responses that are never inspected, so the run passes whether the API returned the documented payload or an empty body with a 200. Four gaps need closing before a collection is a test suite.

• Response assertions. Status code, schema conformance, and required fields. This is the one a schema can generate automatically, which is exactly what Portman does and why schema-derived assertions are worth preferring over hand-written ones: they update when the spec does.
• Chained state. Most real flows are POST /resources then GET /resources/{id} with the id taken from the first response. That requires a test script writing to a collection variable, and no converter infers it because the dependency is not expressed anywhere in OpenAPI.
• Auth acquisition. A security scheme tells the generator which header to send, not how to obtain the token. OAuth 2.0 client credentials flows need a pre-request script or a prior request storing the token.
• Negative cases. A spec documents a 422 response shape but not the input that produces it. Variation testing generates plausible cases from the schema; genuinely meaningful negative cases usually still need to be written.

A useful split is to let the generator own everything derivable from the schema and keep hand-written scripts in a small, separately reviewed set. Regenerating then only overwrites what the schema produced.

How sync drifts, and the settings that prevent it

Sync problems show up on the second generation, not the first, which is why they are usually discovered after the workflow is already relied on. Three behaviors account for most of them.

Renamed paths produce duplicates. Postman creates a new request for the renamed path and leaves the request for the old path in place unless "Remove orphan requests" is enabled. Turning that setting on is the single highest-value configuration change in a synced workflow, and the reason to turn it on deliberately is that it also deletes any request a developer added by hand that does not correspond to a spec endpoint.

Multi-file specs are not syncable. A spec assembled from $ref-linked files has to be bundled into a single document before it can sync, which means the bundling step belongs in CI rather than in someone's local workflow, and the bundled artifact, not the source files, is what the collection tracks.

Regeneration overwrites hand edits. With file-based converters, each run emits a fresh collection, so scripts added in the Postman UI are lost. The durable pattern is to generate the collection in CI, commit it, and treat the Postman workspace as a published view of that file rather than a place where the collection is edited.

Writing an OpenAPI spec that generates a usable collection

Since the mapping is mechanical, improving the collection means improving specific fields in the spec. These four changes produce most of the difference.

1. Give every operation an operationId and a summary. With requestNameSource=Fallback, these become the request name. Without them, requests are named by URL and the collection is navigable only by someone who already knows the API.
2. Treat tags as folder design. folderStrategy=Tags turns tags into folders directly, so tags should reflect how developers think about the API rather than how the service is internally decomposed. Path-based folders mirror URL structure, which is rarely the mental model.
3. Put real examples in the spec. Examples become prefilled request bodies and saved example responses, and a collection whose bodies are schema placeholders cannot be run without editing every request first.
4. Declare securitySchemes and servers explicitly. These generate collection auth and the baseUrl variable. Omitting them means every developer configures auth manually, which is where most first-run failures come from.

When the source spec is produced upstream and cannot be edited directly, the OpenAPI Overlay Specification applies these changes as a separate layer, which keeps the improvements in version control without forking the spec.

Wiring collection generation into CI

Automation is what turns generation from a one-time import into a guarantee. A workable pipeline has four stages and is short enough to live in a single workflow file.

Validate the spec first and fail the build on errors, because everything downstream inherits the spec's defects. Bundle multi-file specs into a single document, both because sync requires it and because converters behave more predictably on bundled input. Generate the collection with pinned options so the diff between runs reflects spec changes rather than tool defaults shifting, then commit the artifact so collection changes are visible in review. Finally, run the collection, with Portman-generated contract tests if contract verification is the goal, through the Postman CLI or Newman against a staging environment, and gate the merge on the exit code.

The ordering matters more than the specific tools. Validation before generation and generation before execution means a broken spec fails at the cheapest point, and a contract regression fails before the collection is published to developers. Pair this with the rest of an API testing strategy rather than treating collection runs as the whole of it: contract tests confirm the API matches its spec, and they say nothing about whether the spec describes the right behavior.

Why Fern fits the spec side of a Postman testing workflow

Fern is the strongest fit for the part of this workflow that determines collection quality rather than the conversion itself. Generated collections inherit their request names, folders, example bodies, and auth configuration from the API definition, so a validated, example-rich definition is what separates a usable collection from an unusable one. Fern produces and maintains that definition across OpenAPI, AsyncAPI, OpenRPC, and gRPC, generates API reference documentation and SDKs from the same source, and can generate a documentation site directly from an existing Postman collection when the collection is what a team already has.

Final thoughts on Postman collection generation tools

Conversion is not the thing to evaluate. Postman's converter is open source, it is what the app itself uses, and every tool here reads the same specs, so the import step is effectively free regardless of which one is chosen. What differs is the test layer: Portman generates assertions from the schema, the Postman CLI and Newman turn a collection into a build gate, and Insomnia and Bruno offer the same substrate with different storage models. Choose on that axis, then spend the remaining effort upstream, because a generated collection cannot be better than the specification it came from. To see how a validated, example-rich API definition feeds documentation, SDKs, and the collections developers test against, book a demo.

FAQ

How do you generate a Postman collection from an OpenAPI spec?

Three paths exist. Import the spec into Postman's Spec Hub, which accepts OpenAPI, AsyncAPI, protobuf, GraphQL, and Smithy and can keep the generated collection in two-way sync with the spec. Run openapi-to-postmanv2 as a CLI or library, which is the same converter Postman uses internally and adds control over folder strategy and request naming. Or run Portman, which converts the spec and injects a generated test suite at the same time. The scripted options are the ones that work in CI.

What is the best tool for generating Postman collections with tests?

Portman, for teams whose goal is contract verification rather than a browsable request library. It generates contract tests asserting the documented happy path for each operation, variation tests for alternate and error conditions, and fuzzing cases, then uploads the collection to Postman or runs it through Newman. Plain converters produce requests with no assertions, so a full run against a live API passes regardless of what the API returned.

Can a Postman collection stay in sync with an OpenAPI spec automatically?

Yes, through two-way sync in Postman's Spec Hub, with two documented constraints. Multi-file OpenAPI specifications are not supported, so a spec split across $ref-linked files must be bundled into a single document first. And renaming a path creates a new request while leaving the old one in place unless the "Remove orphan requests" setting is enabled, which over time leaves a collection full of endpoints that no longer exist.

Should you use Postman CLI or Newman to run collections in CI?

New integrations land in the Postman CLI first, and it is digitally signed by Postman, supports command-line login, and can run a subset of a collection by request or folder ID. Newman is not deprecated and Postman says it has no plans to deprecate it, so it remains a reasonable choice when the collection is a file committed to the repository, since it takes a path or URL with no workspace binding. Both exit non-zero on assertion failure, which is the property a CI gate needs. The distinction worth checking is distribution: Newman installs through npm or Homebrew and is not signed by Postman.

What are the alternatives to Postman for OpenAPI-generated collections?

Kong Insomnia imports OpenAPI and runs collections and unit tests through Inso CLI, with protocol coverage extending to GraphQL, gRPC, WebSockets, and Server-Sent Events. Bruno generates a collection from a spec with bru import openapi and stores it as plain-text .bru files in git, so collection changes are reviewed in pull requests like any other code. Both run headless in CI. The reason teams still produce a Postman collection alongside either one is distribution: it remains the format external developers expect to receive.