Working With Postman

Postman is a REST client that runs as an application in the Chrome browser. You can use it to create API definitions and then group new definitions in collections. You can then import these collections to ReadyAPI.

Notice

In April 2025, ReadyAPI updated Postman Plugin to v3.1.0. ReadyAPI's integration with Postman now includes several enhancements. Key features include:

  • Postman environments can now be imported as ReadyAPI environments, with variables converted to project properties, including support for secrets and dynamic variables.

  • Postman authorization profiles are mapped to ReadyAPI levels, supporting Basic, Digest, NTLM, OAuth 1.0, OAuth 2.0, and AWS Signature.

  • Chai-based tests can now be imported from Postman or created directly in ReadyAPI, with common test expressions translated during import.

  • Pre-request scripts partially support global variables.

  • Post-response scripts are imported as Smart or Chai assertions.

  • JavaScript is supported for load tests but is not recommended due to performance limitations; Groovy remains the preferred option.

To learn more about specific issues addressed in this release, refer to Postman 3.1.0. For information related to the previous version, see Postman 3.0.0.

Note

Postman Plugin version 3.1.0 is compatible only with ReadyAPI 3.60.0 and higher. Users with lower versions won't be able to use version 3.1.0. If you are migrating from Postman and intend to use Plugin 3.1.0, it is recommended that you upgrade to version 3.60.0.

Requirements

  • The collection you import should use local variables. Environment variables are not stored in the collection files, so you cannot import them in ReadyAPI.

Install the plugin

To import the collection to ReadyAPI, you first need to install the Postman support plugin.

  1. Open the Integrations tab:

    ReadyAPI: Select the Integrations tab

  2. Find ReadyAPI Postman Plugin and click Install.

  3. Confirm that you want to download and install the plugin.

    ReadyAPI will do that now.

  4. Restart ReadyAPI.

You can now import your Postman API definitions.

Export a Postman collection

To start working with a Postman collection in ReadyAPI, you need either to get a link to it or to save it as a file.

Save as a file

  1. Click the ellipsis button (...) next to your collection and select Export.

    Export the Postman collection

  2. Select the version to which you want to export the collection and click Export.

    Select version of the Postman collection

    Warning

    Postman no longer provides the option to export V1. The Postman application allows users to export only as V2 or V2.1. V1 Collections version is deprecated in ReadyAPI. It is recommended that users export their V1 collection as 2.X.

  3. Select the location you want to save the collection to and click Save.

Import a Postman collection

To import a Postman collection to ReadyAPI:

  1. Select File > Create Project via Integration .

  2. In the dialog that appears, switch to the Integration tab and click Postman collection.

    ReadyAPI: Importing a Postman collection

  3. Paste the link to your Postman collection, or click Browse and select the Postman collection to be imported.

  4. Click OK.

ReadyAPI will create a new project and import all APIs in the collection. If the collection has tests, ReadyAPI creates a new SOAP or REST Request test step in functional tests for each API definition with tests.

Note

ReadyAPI supports basic conversion of Postman scripts and variables during import. Starting from Postman Plugin 3.1.0, it can also evaluate dynamic assignments using the pm.collectionVariables API. For more details on how ReadyAPI handles these during import, see Conversion rules.

Import Postman environments

Postman does not include environments in collection files, but you can export environments separately as JSON files and then import the files into ReadyAPI.

To import a Postman environment into ReadyAPI:

  1. In the Projects tab, right-click your project and select Endpoints & Environments.

  2. In the Endpoints & Environments dialog, click RAPI_screenshot_import.png to add a new environment from a Postman JSON export file.

  3. In the Load Postman Environment dialog:

    • Browse to and select your exported environment file.

    • (Optional) Select:

      • Copy endpoints from 'No Environment': This option copies the API endpoints from the No Environment setup and adds them to the imported environment.

      • Copy authorization from 'No Environment': This option copies project-level and request-level authorization profiles. API-level profiles will default to No Authorization.

    RAPI_screenshot_load__Postman_environment.png

  4. Click OK to complete the import.

What happens during import

  • ReadyAPI creates a new environment from the imported file.

  • The system converts Postman variables to custom project properties.

  • You can use these properties in property expansions throughout your project.

Note

All environments in a ReadyAPI project share the same set of variables. When you import a new environment, ReadyAPI merges its variables with those from existing environments.

Handling Secret Variables

If the Postman environment includes secret variables and your ReadyAPI project uses password-based encryption, ReadyAPI automatically encrypts those variables during import.

Vault Variables

Postman Vault Variables (for example, {{vault: some variable}}) are not included in exported files. If your collection references vault variables, ReadyAPI prompts you with a Resolve Vault Variables dialog so you can manually enter the missing values.

Resolve Vault Variables Dialog

Dynamic Variables

Postman supports dynamic variables like $randomUUID or $timestamp. ReadyAPI imports these as custom project properties, but they will not behave dynamically. You can use them in property expansions, but they won’t auto-generate new values.

Import authorization profiles

When importing Postman environments into ReadyAPI, it’s crucial to understand the mapping process of authorization profiles. These profiles determine request authentication, so knowing how they are imported and applied in ReadyAPI ensures a smoother integration.

Mapping of Authorization Profiles

  • Collection-level Authorization in Postman → Project-level Authorization in ReadyAPI

  • Folder-level Authorization in Postman → Request-level Authorization in ReadyAPI

    Note

    ReadyAPI doesn't support Postman’s folder structure. Setting authorization at the folder level applies to the individual requests instead, but only if those requests don’t have their own specific authorization profile.

  • Request-level Authorization in Postman → Request-level Authorization in ReadyAPI

Supported authorization profiles

ReadyAPI supports the import of the following Postman authorization profiles:

  • Basic

  • Digest

  • NTLM

  • OAuth 1.0

  • OAuth 2.0

  • AWS Signature

A warning will appear in the logs if you attempt to import any unsupported authorization profiles.

Note

Authorization profiles in ReadyAPI and Postman have slight differences in their parameter sets. As a result, some parameters from Postman profiles may be missing in the imported ReadyAPI profiles.

Copying Authorization Profiles

When importing a Postman environment, you have the option to copy authorization profiles from “No Environment”. This will copy the authorization profiles set at both the project and request levels. However, for API-level authorization, "No Authorization" will be applied by default.

Conversion rules

ReadyAPI project structure differs from the Postman collection structure, so it has several conversion rules.

  • API requests are converted to API definitions on the Projects page.

  • Requests with unsupported HTTP methods are skipped, and a message is posted in the log.

  • Collection variables and global variables set in the preRequestScript and tests are converted to custom project properties.

  • Dynamic assignments using pm.collectionVariables.set(...) and get(...) are evaluated at import and converted into static project-level properties. These values do not update dynamically after import.

  • The {{property}} elements in request URLs and the globals["property"] elements in scripts are converted to property expansions (${#Scope#property}).

  • Request headers are converted to HEADER request parameters.

  • If the collection has any tests, ReadyAPI creates a test case with a REST or SOAP request test step for each request with tests in the collection.

  • Assertions are created for all the corresponding elements in tests:

    • tests["Status code is 200"] = responseCode.code === 200 is converted to Valid HTTP Status Codes assertion.

    • tests["Status code is not 401"] = responseCode.code !== 401 is converted to Invalid HTTP Status Codes assertion.

    • tests["Response time is less than 300ms"] = responseTime < 300 is converted to Response SLA assertion.

    • tests["Body is correct"] = responseBody === "abc def" is converted to Equals assertion.

    • tests["Body matches string"] = responseBody.has("abc") is converted to Contains assertion.

    • tests["Content Type is present"] = postman.getResponseHeader("Content-Type") is converted to Script assertion.

Limitations

  • Script Syntax Compatibility: Currently, ReadyAPI supports only the older style of script syntax. If you are using newer syntax in Postman (such as the pm.collectionVariables.set(...) or pm.collectionVariables.get(...) methods), it will be translated into static project properties during import.

  • Postman Environments: Postman does not store environments within the collection file. As a result, environments from Postman are not imported into ReadyAPI directly. You need to export Postman environments separately as JSON files and import them into ReadyAPI manually.

  • Dynamic Variables: Dynamic values assigned with pm.collectionVariables.set(...) in Postman are converted into static project properties during the import process in ReadyAPI. This means that while the values are available in the imported project, they do not behave dynamically as they would in Postman. They can be used in property expansions, but do not auto-generate new values.

  • Pre-request Script Limitations: ReadyAPI does not have a direct equivalent to Postman’s Pre-request Script. While earlier versions of the plugin allowed setting global variables in the pre-request script (using the old syntax), this feature has been preserved in version 3.1.0. Global variables can now be set using both old and new syntax, but the rest of the pre-request script content is ignored during import.

  • Post-response Script Import: Postman old syntax tests are imported as ReadyAPI Smart Assertions. Any tests not using the old syntax are imported as ReadyAPI Chai Assertions. A single Chai assertion is created for each request, just like in Postman, where one post-response script corresponds to one request.

  • Load Tests and JavaScript Performance: JavaScript is supported for load tests in ReadyAPI, but we do not recommend it due to performance limitations. The JavaScript engine in ReadyAPI is slower than Groovy, which remains the preferred option for load testing. The Chai Assertion engine is managed differently, adding additional constraints. For best performance, we advise to use Groovy for load tests.

Chai assertions support

You can create Chai assertions directly in ReadyAPI or import them from a Postman collection. If the imported script contains invalid JavaScript syntax, ReadyAPI shows a popup and skips the problematic script.

Available objects in the script area

Java Objects

  • log

  • context

  • messageExchange

JavaScript Objects

  • chai – Contains the pre-imported Chai library. You can use it out of the box. All methods from the Chai Introduction are available.

  • ready – Contains the test(assertionName, assertionBody) method. Use this method to replace the pm.test(...) in Postman.

  • ajv – Contains a ready-to-use instance of the Ajv library.

  • xml2js – Contains a ready-to-use instance of the xml2js library.

Note

The standard JavaScript console object is not available. Use the log Java object for logging, just like in other ReadyAPI JavaScript scripts.

Java vs JavaScript Types

Java and JavaScript types are not fully compatible. When using log, context, or messageExchange in JavaScript, cast the values appropriately—for example:

String(messageExchange.response.contentAsString)

If you skip proper casting, a TypeError may occur. The error message highlights the line that needs adjustment, but ReadyAPI can’t provide additional details due to internal JS exceptions.

Writing tests

You can write tests in two ways:

  • Use plain Chai assertions.

    RAPI_screenshot_plain_Chai_assertions.png

  • Group Chai assertions using the ready.test() method, similar to Postman’s pm.test().

    RAPI_screenshot_group_Chai_assertions.png

    Note

    Grouped assertions improve error reporting by collecting test-level failures with detailed feedback for each assertion.

Postman-to-ReadyAPI Translation

Use the table below to convert commonly used Postman methods and variables to their ReadyAPI equivalents:

Table 20. Postman-to-ReadyAPI Translation

Postman

ReadyAPI

pm.response.code

messageExchange.response.getStatusCode()

pm.response.text()

String(messageExchange.response.contentAsString)

pm.response.to.have.jsonSchema(schema)

chai.expect(ajv.validate(schema, JSON.parse(String(messageExchange.response.contentAsString)))).to.be.true

tv4.validate(json, schema)

ajv.validate(schema, json)

pm.response.to.have.status(status)

chai.expect(String(messageExchange.responseHeaders.get("#status#"))).to.include(status)

pm.response.to.have.body(body)

chai.expect(String(messageExchange.response.contentAsString)).to.eql(body)

pm.response.to.have.header(header)

chai.expect(messageExchange.responseHeaders.hasValues(header)).to.be.true

pm.response.headers.get(header)

String(messageExchange.responseHeaders.get(header))

pm.response.body

String(messageExchange.response.contentAsString)

pm.response.headers

messageExchange.response.responseHeaders

pm.response.responseTime

messageExchange.response.timeTaken

pm.(collectionVariables | environment | globals).get(propertyName)

String(context.expand("${#Project#propertyName}"))

pm.variables.get(propertyName)

String(context.expand("${#TestCase#propertyName}"))

pm.(collectionVariables | environment | globals).set(propertyKey, propertyValue)

context.testCase.testSuite.project.setPropertyValue(propertyKey, propertyValue)

pm.variables.set(propertyKey, propertyValue)

context.testCase.setPropertyValue(propertyKey, propertyValue)

require("xml2js")

xml2js

pm.response.json()

JSON.parse(messageExchange.response.contentAsString)

console.(warn | debug | error)(contentToPrint)

log.logLevel(String(contentToPrint))

console.(info | log)(contentToPrint)

log.info(String(contentToPrint))

pm.cookies.has(cookie)

messageExchange.cookies.get(cookie) != null

pm.cookies.get(cookie)

String(messageExchange.cookies.get(cookie))

pm.test(...)

ready.test(...)

pm.expect(...)

chai.expect(...)

await pm.vault.get(variableName)

String(context.expand("${#Project#variableName}"))

pm.variables.replaceIn({{$dynamicVariable}})

String(context.expand("${#Project#dynamic-variable-dynamicVariable}"))



Next steps

See Also

In this section:
© 2025
Publication date: