API Monitoring & Testing: Importing and Exporting Tests

You can export tests to our Runscope Export Format, and import request definitions from other services to create Runscope API tests.

Exporting Runscope API Test Steps

The Runscope Export Format is a JSON representation of your API Test's steps. The downloaded file can be imported into any Runscope team's bucket to create a new test with the same step information. To learn more about the structure of exported tests, visit our API Test Detail specification.

Importing Runscope API Tests

The following import formats are supported:

Runscope Export Format

You can import Runscope API test steps that have been previously exported to our Runscope Export Format. Importing and exporting API tests is useful for sharing tests between Runscope teams or accounts. Imported tests must have at least one test step, and fewer than 100 steps.

SmartBear Ready! API / SoapUI

From within Ready! API (under Projects), export your test suite as a Swagger 2.0 JSON file (right click on suite, Export Swagger) and use the Runscope Swagger importer to create tests from the export.

Swagger 2.0 API Definitions (JSON)

You can import a Swagger 2.0 API definition in JSON format into a Runscope test. Each definition parses out to one test, and each Operation Object corresponds to one test request step. JSON pointers are supported, but multi-file uploads are not.

Because the Swagger specification describes what types of values may appear in a request, but doesn't necessarily specify actual values, we make heavy use of placeholders in the form of variables. When you first import a test, you'll have to give values to these variables.


The top-level Swagger host field is extracted and set to a variable {{host}}. It acts the base url for every request in a test. If no host field is present, we default {{host}} to yourapihere.com but you can change it after the import is completed.


If a basePath is present on the Swagger object, it is prepended to all request paths. For example, an API with host yourapihere.com, a basePath /v2, and a path /resource would get assembled to yourapihere.com/v2/resource.


Parameters on the Swagger Object are parsed based on the type of parameter. Both parameters at the Paths Object level, and at the Operation Object level are honored, with any Operation-level parameter overwriting a Paths-level parameter of the same name. For all parameters, we make use of the name and in fields. Form parameters use additional information from their Operation Object's consumes field.

  • Query Parameters

    For each query parameter object, we extract the name field and use it as a query parameter field name. The value of the query parameter is set to an uninitialized variable of the same name. For instance, a query parameter named "id" would get appended onto a query string: as ?id={{id}}. It is up to you to set the value of the variable to a real ID to use in a request step.

  • Header Parameters

    Header parameters are parsed out of the header parameter object in the same way as query parameters; however, the value of the name field, and corresponding uninitialized variable are set as the header name and value in a test request step.

  • Path Parameters

    Path parameters are replaced by uninitialized variables. A Swagger path with a parameter like /user/{id} is imported as /user/{{id}}.

  • Form Parameters

    Form Parameters are parsed same way as Query parameters, with the exception that if multipart/form-data is the only content-type listed in the Operation Object's consume field, we skip parsing the form parameters.

  • Body Parameters

    When a body parameter is present, an uninitialized variable set to the parameter object's name appears as the raw body. We do not currently support parsing of a body's Schema object.

Security Requirement Object

If a Security Requirement Object is present on an Operation Object, we first determine if there's an entry of type APIAuth. If there is, we parse the corresponding object the same way we would a query parameter object, if the in field is "query," or a header parameter object, if the in field is "header." If there is no APIAuth type object, and there's an object of type "basic," we set basic auth in the test request step as follows: username gets a value of {{username}}, and password gets the value {{password}}. We do not currently support OAuth2.0.


We currently allow imports of Postman dump files--which, in their data, include all collections, environments, globals, and header presets--as well as imports of individual Postman collections v1. Header presets, environments (except for global variables), and scripts are not supported and will be ignored. Learn more about Postman data formats.

Postman Dump Files

Each collection is turned into an API test, and any globals are turned into initial variables in each test.

Postman Collections v1

Importing an individual collection will create a single test. Variable values are not included because they are not present in the collection file.

HTTP Archive Files (HAR)

Currently, the only HAR field we support is entries, which represent HTTP requests. Pages, comment, browser, creator are ignored.

You can generate a HAR file from Fiddler and Charles Proxy from their Export menus.

VCR Cassettes

VCR versions 1 and 2 are supported, and we accept import formats in YAML or JSON. Currently not supported are the body-encoding field, and the http version fields on the response object.


Install the Runscope API Test generator extension in Paw and upload the generated file using Runscope Export Format.

Need help? We have you covered.

View the docs or contact our support team and we'll get back to you as soon as we're able to respond.