Portman 👨🏽‍🚀

Port OpenAPI Spec to Postman Collection, with contract & variation tests included!

Portman leverages OpenAPI documents, with all its defined API request/response properties, to power your Postman collection. Let Portman do all the work and inject contract & variation tests with a minimum of configuration. Customize the Postman requests & variables with a wide range of options to assign & overwrite variables.

> [!IMPORTANT]
> Important Change: If you are using version 1.28.0 with a custom Postman config file specified by the --postmanConfigFile flag, please ensure that the parametersResolution option is set to either "Example" or "Schema". The options requestParametersResolution and exampleParametersResolution are deprecated openapi-to-postman options.

Why use Portman?

Convert your OpenAPI spec to Postman, generate contract & variation tests, upload the Postman collection & run the tests through Newman. Include the Portman CLI as part of an automated process for injecting the power of Portman directly into your CI/CD pipeline.

Read the full blog post

Features

With Portman, you can:

• [x] Convert an OpenAPI document to a Postman collection
  • [x] Support for OpenAPI 3.0
  • [x] Support for OpenAPI 3.1 (beta)
• Extend the Postman collection with capabilities
  • [x] Inject Postman Contract Tests - learn more
  • [x] Assign collection variables - learn more
  • [x] Inject Postman Variation Tests - learn more
  • [x] Inject Postman Integration Tests
  • [x] Inject Postman with Pre-request & Tests scripts on a collection or operation level - learn more
  • [x] Modify Postman requests - learn more here and here
  • [x] Fuzz Postman requests - learn more
• [x] Upload the Postman collection to your Postman app - learn more
• [x] Test the Postman collection with Newman - learn more
• [x] Split the configuration into multiple files using $ref
• [x] Manage everything in config file for easy local or CI/CD usage - learn more

Getting started

1. Install Portman
2. Initialize Portman CLI configuration by running: $ portman --init

OR

1. Install Portman
2. Copy .env.example to .env and add environment variables you need available to your collection
3. Copy/rename and customize each of the ____.default.json config files in the root directory to suit your needs
4. Start converting your OpenAPI document to Postman

OR

If you have an existing OpenAPI specification, try running Portman without any special setup to see how it can generate a Postman collection with contract tests with it's default configuration.

1. Install Portman
2. Run portman on your OpenAPI spec, ie:

• npx portman -l my-openapi-spec.yaml
• (if your spec is hosted use the -u parameter, ie:
  • npx portman -u https://petstore3.swagger.io/api/v3/openapi.json

This will generate a postman collection that contains a request for every method:endpoint combination defined in your spec, and include a set of "Contract Tests" for each one. You can learn more about contract tests, and how to examine the generated collection here.

(Running portman with no explicit configuration is the same as running it with this configuration file)

All configuration options to convert from OpenAPI to Postman can be found in the openapi-to-postman package documentation. All configuration options to filter flags/tags/methods/operations/... from OpenAPI can be found in the openapi-format package documentation or using the online openapi-format playground.

Installation

Local Installation (recommended)

You can add the Portman CLI to the node_modules by using:

$ npm install --save @apideck/portman

or using yarn:

$ yarn add @apideck/portman

Note that this will require you to run the Portman CLI with npx @apideck/portman -l your-openapi-file.yaml or, if you are using an older version of npm, ./node_modules/.bin/portman -l your-openapi-file.yaml.

Global Installation

$ npm install -g @apideck/portman

NPX usage

To execute the CLI without installing it via npm, use the npx method.

$ npx @apideck/portman -l your-openapi-file.yaml

CLI Usage

Usage: -u  -l  -b  -t 

Options:
 --help                     Show help                                                                        [boolean]
 --version                  Show version number                                                              [boolean]
 --url,-u                   URL of OAS to port to Postman collection                                         [string]
 --local, -l                Use local OAS to port to Postman collection                                      [string]
 --baseUrl, -b              Override spec baseUrl to use in Postman                                          [string]
 --output, -o               Write the Postman collection to an output file                                   [string]
 --oaOutput                 Write the (filtered) OpenAPI file to an output file                              [string]
 --runNewman, -n            Run Newman on newly created collection                                           [boolean]
 --newmanRunOptions         JSON stringified object to pass options for configuring Newman                   [string]
 --newmanOptionsFile        Path/URL to Newman options file to pass options for configuring Newman           [string]
 --newmanIterationData, -d  Iteration data to run Newman with newly created collection                       [string]
 --localPostman             Use local Postman collection, skips OpenAPI conversion                           [string]
 --syncPostman              Upload generated collection to Postman (default: false)                          [boolean]
 --syncPostmanCollectionIds Synchronises the IDs of newly created postman collections with those already
                            on Postman, useful when you want to use Postman pull request (default: false)    [boolean]
 --postmanFastSync          Postman sync creates new collection (new UID),instead of update (default: false) [boolean]
 --postmanRefreshCache      Postman sync will refresh all local cached Postman API data (default: false)     [boolean]
 --postmanUid, -p           Postman collection UID to upload with the generated Postman collection           [string]
 --postmanWorkspaceName     Postman Workspace name to target the upload of the generated Postman collection  [string]
 --includeTests, -t         Inject Portman test suite (default: true)                                        [boolean]
 --bundleContractTests      Bundle Portman contract tests in a separate folder in Postman (default: false)   [boolean]
 --portmanConfigFile, -c    Path/URL to Portman settings config file (portman-config.json)                   [string]
 --postmanConfigFile,-s     Path to openapi-to-postman config file (postman-config.json)                     [string]
 --filterFile               Path/URL to openapi-format config file (oas-format-filter.json)                  [string]
 --envFile                  Path to the .env file to inject environment variables                            [string]
 --collectionName           Overwrite OpenAPI title to set the Postman collection name                       [string]
 --cliOptionsFile           Path/URL to Portman CLI options file                                             [string]
 --ignoreCircularRefs       Ignore circular references in OpenAPI spec (default: false)                      [boolean]
 --logAssignVariables       Toggle logging of assigned variables (default: true)                             [boolean]
 --warn/--no-warn           Toggle warnings for missing openApiOperationIds (default: true)                  [boolean]
 --init                     Configure Portman CLI options in an interactive manner                           [string]
 --extraUnknownFormats      Add extra unknown formats to json schema tests                                   [array]

Environment variables as Postman variables

Portman uses dotenv to not only access variables for functionality, but you can also add environment variables that you'd like declared within your Postman environment. Simply prefix any variable name with PORTMAN_, and it will be available for use in your Postman collection as the camel-cased equivalent. For example:

PORTMAN_CONSUMER_ID=test_user_id

will be available in your collection or tests by referencing:

{{consumerId}}

It is possible to set a spec-specific .env file, that lives next to your config files. The path can be passed in via envFile cli option. This is useful if you have Portman managing multiple specs that have unique environment requirements.

By default, Portman will leverage any ENVIRONMENT variable that is defined that starts with PORTMAN_.

Another option to set variables is by configuring them as collectionVariables in the globals section of your Portman configuration.

CLI Options

Initialize Portman CLI configuration

portman --init

The init option will help you to configure the cliConfig options and put the default config, env file in place to kick-start the usage of Portman.

Pass in the remotely hosted spec

portman -u https://specs.apideck.com/crm.yml

Overwrite the baseUrl in spec and run Newman

portman -u https://specs.apideck.com/crm.yml -b https://localhost:3050 -n true

Path pass to a local data file for Newman to use for iterations

portman -u https://specs.apideck.com/crm.yml -b https://localhost:3050 -n true -d ./tmp/newman/data/crm.json

Pass the path to a local spec (useful when updating your specs) and output Postman collection locally

portman -l ./tmp/specs/crm.yml -o ./tmp/specs/crm.postman.json

Skip tests and just generate collection

portman -l ./tmp/specs/crm.yml -t false

Filter OpenAPI and generate collection

portman -u https://specs.apideck.com/crm.yml --filterFile examples/cli-filtering/oas-format-filter.json

For more details, review the cli-filtering example.

Add extra forms to Json schema validation

portman -l ./tmp/specs/crm.yml -o ./tmp/specs/crm.postman.json --extraUnknownFormats ulid one two

This makes the schema validation more lenient, and solves problems with unknown formats

Upload newly generated collection to Postman, which will upsert the collection, based on the collection name

portman -l ./tmp/specs/crm.yml --syncPostman

Upload newly generated collection to Postman using the collection UID to overwrite the existing.

portman -l ./tmp/specs/crm.yml --syncPostman -p 9601963a-53ff-4aaa-92a0-2e70a8a2a748

When a collection gets large, the Postman API will compare all the requests when updating the collection. This can take some time even result in 5xx errors. To overcome this, you can use the --postmanFastSync option. This option will sync your collection to Postman by using "delete" and "create" operations instead of the "update".

REMARK: Using --postmanFastSync will result in a new Postman collection and Postman UID for each sync.

portman -l ./tmp/specs/crm.yml --syncPostman --postmanFastSync

Portman caches a set of Postman API data to facilitate faster lookups and uploads, preventing unnecessary connecting to the Postman API. In case you need to reset the cache you simply remove the .portman.cache.json file or set the --postmanRefreshCache option when running the Postman sync.

portman -l ./tmp/specs/crm.yml --syncPostman --postmanRefreshCache

Pass custom paths for config files

All configuration options to convert from OpenAPI to Postman can be on the openapi-to-postman package documentation. Portman provides a default openapi-to-postman configuration postman-config.default.json, which will be used if no custom config --postmanConfigFile is passed.

Portman configuration file in JSON format:

portman -u https://specs.apideck.com/crm.yml -c ./tmp/crm/portman-config.json -s ./common/postman-config.json

Portman configuration file in YAML format:

portman -u https://specs.apideck.com/crm.yml -c ./tmp/crm/portman-config.yaml -s ./common/postman-config.json

Pass all CLI options as JSON/YAML file

All the CLI options can be managed in a separate configuration file and passed along to the portman command. This will make configuration easier, especially in CI/CD implementations.

Portman CLI options settings in JSON format

portman --cliOptionsFile ./examples/cli-options/portman-cli-options.json

Portman CLI options settings in YAML format

portman --cliOptionsFile ./examples/cli-options/portman-cli-options.yaml

All the available Portman CLI options can be used in the config file. By passing the CLI options as parameter, you can overwrite the defined CLI options defined in the file.

For more details, review the cli-options example.

Run Newman with Newman options

All Newman configuration options to run Newman can be passed along through Portman.

portman -u https://specs.apideck.com/crm.yml -c ./tmp/crm/portman-config.json --runNewman --newmanOptionsFile ./tmp/crm/newman-options.json

For more details, review the cli-options example.

NOTE: Newman is set to ignore redirects to allow for testing redirect response codes. If you are running collections within Postman UI, you'll need to ensure Postman is set to the same, or your redirect tests will fail.

> Postman > Preferences > Automatically follow redirects > OFF

Output

Without specifying the output location, your generated Postman Collection is written to ./tmp/converted/${specName}.json if you are manually importing to Postman or need to inspect for debugging.

By using -o or --output parameter, you can define the location where the Postman collection will be written.

portman -l ./tmp/specs/crm.yml -o ./tmp/specs/crm.Postman.json

Portman settings

The Portman settings consist out of multiple parts:

• version : which refers to the JSON Portman configuration version.
• tests : which refers to the definitions for the generated contract & variance tests.
  • contractTests : refers to the options to enabled autogenerated contract tests.
  • contentTests : refers to the additional Postman tests that check the content.
  • variationTests : refers to the options to define variation tests.
  • integrationTests : refers to the options to define integration tests.
  • extendTests : refers to the custom additions of manually created Postman tests.
• assignVariables : which refers to setting Postman collection variables for easier automation.
• overwrites : which refers to the custom additions/modifications of the OpenAPI/Postman request data.
• operationPreRequestScripts : which refers to injecting Postman Pre-request Scripts for requests.
• globals : which refers to the customization that applies for the whole Postman collection.

Portman targeting

It is possible to inject Postman tests and pre-register scripts, assign variables and overwrite query params, headers, request body data with values.

To be able to do this very specifically, there are options to define the targets:

• openApiOperationId (String) : References to the OpenAPI operationId, example: leadsAll

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : References to a combination of the OpenAPI method & path, example: GET::/crm/leads

• excludeForOperations (Array) : References to OpenAPI operations that will be skipped for targeting. It supports both the openApiOperationId and openApiOperation format, example: ["leadsAdd", "GET::/crm/leads/{id}"]

An openApiOperationId is an optional property. To offer support for OpenAPI documents that don't have operationIds, we have added the openApiOperation definition, which is the unique combination of the OpenAPI method & path, with a :: separator symbol. The targeting option excludeForOperations is really useful when using wildcards, to allow exclusions from the wildcard.

This will allow targeting for very specific OpenAPI items.

To facilitate managing the filtering, we have included wildcard options for the openApiOperation option, supporting the methods & path definitions.

REMARK: Be sure to put quotes around the target definition.

• Strict matching example: "openApiOperation": "GET::/crm/leads", This will target only the "GET" method and the specific path "/crm/leads"

• Method wildcard matching example: "openApiOperation": "*::/crm/leads", This will target all methods ('get', 'put', 'post', 'delete', 'options', 'head', 'patch', 'trace') and the specific path "/crm/leads"

• Path wildcard matching example: "openApiOperation": "GET::/crm/*" This will target only the "GET" method and any path matching any folder behind the "/crm", like "/crm/companies" and "/crm/leads".

• Method & Path wildcard matching example: "openApiOperation": "*::/crm/*", A combination of wildcards for the method and path parts is even possible.

Portman - tests properties

The Portman tests is where you would define the tests that would be applicable and automatically generated by Portman, based on the OpenAPI document. The contract tests are grouped in an array of contractTests.

contractTests options

• openApiOperationId (String) : References to the OpenAPI operationId. (example: leadsAll)

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : References to a combination of the OpenAPI method & path (example: GET::/crm/leads)

• excludeForOperations (Array | optional) : References to OpenAPI operations that will be skipped for targeting, example: ["leadsAdd", "GET::/crm/leads/{id}"]

• statusSuccess (Boolean) : Adds the test if the response of the Postman request returned a 2xx

• statusCode (Boolean, HTTP code) : Adds the test if the response of the Postman request return a specific status code.

• responseTime (Boolean) : Adds the test to verify if the response of the Postman request is returned within a number of ms.

  • maxMs (number) : Define the expected number of ms for the responseTime check.

• contentType (Boolean) : Adds the test if the response header is matching the expected content-type defined in the OpenAPI spec.

• jsonBody (Boolean) : Adds the test if the response body is matching the expected content-type defined in the OpenAPI spec.

• schemaValidation (Boolean) : Adds the test if the response body is matching the JSON schema defined in the OpenAPI spec. The JSON schema is inserted inline in the Postman test.

  • additionalProperties (Boolean) : Extend the expected JSON schema used for the schemaValidation by setting all the additionalProperties.

• headersPresent (Boolean) : Adds the test to verify if the Postman response header has the required header names present, like defined in the OpenAPI spec.

For more details, review the contract-tests example.

variationTests options

• openApiOperationId (String) : References to the OpenAPI operationId for which a variation will be created. (example: leadsAll)

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : References to a combination of the OpenAPI method & path for which a variation will be created. (example: GET::/crm/leads)

• excludeForOperations (Array | optional) : References to OpenAPI operations that will be skipped for targeting, example: ["leadsAdd", "GET::/crm/leads/{id}"]

• openApiResponse (String | optional) : References to the OpenAPI response object code/name for which a variation will be created. (example: "404"). If not defined, the 1st response object from OpenAPI will be taken as expected response. If the configured openApiResponse code is not defined in the OpenAPI document, Portman will not generate a variation for the targeted operations.

• overwrites : which refers to the custom additions/modifications of the OpenAPI/Postman request data, specifically for the variation.

• fuzzing : Fuzz testing sets unexpected values for API requests, to cause unexpected behavior and errors in the API response.

• tests : which refers to the definitions for the generated contract & variance tests for the variation.

  • contractTests : refers to the options to enabled autogenerated contract tests for the variation.
  • contentTests : refers to the additional Postman tests that check the content for the variation.
  • extendTests : refers to the custom additions of manual created Postman tests to be included in the variation.

• assignVariables : This refers to setting Postman collection variables that are assigned based on variation.

For more details, review the content-variation example.

integrationTests options

• name (String) : As Integration tests will normally contain multiple operations, this is the folder name that will be generated in the Integration Tests folder in your Postman collection.
• operations (Array) : Array of operations to be performed

Portman - contentTests properties

Content tests will validate if the response property values will match the expected defined values. While the Portman tests verify the "contract" of the API, the contentTests will verify the content of the API.

contentTests options

• openApiOperationId (String) : References to the OpenAPI operationId. (example: leadsAll)

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : References to a combination of the OpenAPI method & path (example: GET::/crm/leads)

• excludeForOperations (Array | optional) : References to OpenAPI operations that will be skipped for targeting, example: ["leadsAdd", "GET::/crm/leads/{id}"]

• responseBodyTests (Array) : Array of key/value pairs of properties & values in the Postman response body.

  • key (String) : The key that will be targeted in the response body to check if it exists.
    • To look up a key within in array of objects, you can use an array index (example data.websites[0].url) or a * wildcard (example: data.websites[*].url) which uses the value to match an object in an array.
    • To test a response body that is a single value instead of a JSON object, set this to '.'
  • value (String) : The value that will be used to check if the value in the response body property matches.
  • contains (String) : The value that will be used to check if the value is present in the value of the response body property.
  • oneOf (String[],Number[],Boolean[]) : The value that will be used to check one of the values is matching the response body property.
  • length (Number) : The number that will be used to check if the value of the response body property (string/array) has a length of the defined number.
  • minLength (Number) : The number that will be used to check if the value of the response body property (string/array) has a minimum length of the defined number.
  • maxLength (Number) : The number that will be used to check if the value of the response body property (string/array) has a maximum length of the defined number.
  • notExist (Boolean) : The inverse of the key check that verify if the key does not exist in the response body.
  • assert (String) : A custom Postman assertion to check if the value in the response body property matches with the provided assertion (example: not.to.be.null).

• responseHeaderTests (Array) : Array of key/value pairs of properties & values in the Postman response header.

  • key (String) : The header name that will be targeted in the response header to check if it exists.
  • value (String) : The value that will be used to check if the value in the response header matches.
  • contains (String) : The value that will be used to check if the value is present in the value of the response header.
  • oneOf (String[],Number[],Boolean[]) : The value that will be used to check one of the values is matching the value of the response header.
  • length (Number) : The number that will be used to check if the value of the response header has a length of the defined number of characters.
  • minLength (Number) : The number that will be used to check if the value of the response header has a minimum length of the defined number of characters.
  • maxLength (Number) : The number that will be used to check if the value of the response header has a maximum length of the defined number of characters.
  • notExist (Boolean) : The inverse of the key check that verify if the key does not exist in the response header.
  • assert (String) : A custom Postman assertion to check if the value in the response header matches with the provided assertion (example: not.to.be.null).

For more details, review the content-tests example.

Portman - extendTests properties

When you need to add additional tests or overwrite the Portman-generated test, you can use the extendTests to define the raw Postman tests. Anything added in the tests array will be added to the Postman test scripts.

extendTests options

• openApiOperationId (String) : References to the OpenAPI operationId. (example: leadsAll)

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : References to a combination of the OpenAPI method & path (example: GET::/crm/leads)

• excludeForOperations (Array | optional) : References to OpenAPI operations that will be skipped for targeting, example: ["leadsAdd", "GET::/crm/leads/{id}"]

• tests (Array) : Array of additional Postman test scripts. Values can be the script content or path to the script file (with file: prefix).

• overwrite (Boolean true/false | Default: false) : Resets all generateTests and overwrites them with the defined tests from the tests array.

• append (Boolean true/false | Default: true) : Place the tests after (append) or before (prepend) all generated tests.

---

Portman - assignVariables properties

The "assignVariables" allows you to set Postman collection variables for easier automation.

assignVariables options

• openApiOperationId (String) : Reference to the OpenAPI operationId for which the Postman pm.collectionVariables will be set. (example: leadsAll)

• openApiOperationIds (Array) : References to an array of OpenAPI operationIds, for which the Postman pm.collectionVariables will be set. example: ['leadsAll', 'companiesAll', 'contactsAll']

• openApiOperation (String) : Reference to the combination of the OpenAPI method & path, for which the Postman pm.collectionVariables will be set. (example: GET::/crm/leads)

• excludeForOperations (Array | optional) : References to OpenAPI operations that will be skipped for targeting, example: ["leadsAdd", "GET::/crm/leads/{id}"]

• collectionVariables (Array) : Array of key/value pairs to set the Postman collection variables.

  • responseBodyProp (String) : The property for which the value will be taken from the response body and set the value as the pm.collectionVariables value. To store the root level, use . as key.
  • responseHeaderProp (String) : The property for which the value will be taken from the response header and set the value as the pm.collectionVariables value.
  • requestBodyProp (String) : The property for which the value will be taken from the request body and set the value as the pm.collectionVariables value.
  • value (String) : The defined value that will be set as the pm.collectionVariables value. The value can be generated using template expressions. For the full list of template expressions, check the Assign & Overwrite example
  • name (string OPTIONAL | Default: .) : The desired name that will be used to as the Postman variable name. If the name is not provided, Portman will generate a variable name, using the .. You can pass your own template expressions, to dynamically generate variable names. The template can contain the following dynamic expressions: `` results in the OpenAPI operation ID (example leadsAdd), `