Creating load tests from Swagger/OpenAPI and Postman

Algebran Yazılım & Danışmanlık · Published 5 October 2026

Most teams have a Swagger/OpenAPI document describing their API, or a Postman collection they use every day. The endpoints, parameters, example bodies and the way to authenticate are already written there; starting from them instead of writing a load test from scratch saves hours. But a document describes what an API can do, not how its users behave. This guide covers what can come from the document automatically, what you need to complete by hand, and how to set up variables and environments.

What comes from the document?

• Requests: the method, path and server address of every operation. servers in OpenAPI, host and basePath in Swagger 2.0, the request URLs in Postman.
• Parameters and bodies: path and query parameters, required headers, JSON or form bodies. A document example is used when there is one; otherwise a sample value is derived from the schema.
• Authentication: a bearer token, basic auth, or an API key in a header or the query. The value itself is not in the document (and should not be); only its shape comes over.
• The expected response: the status code the document counts as success (200, 201…), as the simplest check.

What the document does not know

A test that calls every endpoint of the document once does not resemble what your users do. You add these yourself:

• Flow and proportions. In real traffic, list and detail requests far outnumber order creation. Pick only the flows that matter, put them in order (login, search, detail, cart) and keep them close to production proportions.
• Correlation. A value from one response (the login token, the id of a new order) is used in later requests. The document does not know this link; you define the extraction from the response (with JSONPath, for example).
• Realistic data. The same example id on every request comes back from the cache and makes the system look faster than it is. Take ids and users from a data file or generators.
• The load model and think time. How many users, at what rate, for how long, and how many seconds between requests (load test types).

Requests that change data

Turning every operation of a document into a test wholesale is dangerous: the load test repeats every POST, PUT and DELETE request on every iteration. A test run against the wrong environment can create or delete thousands of records. Start from read requests, add write requests deliberately and one by one, and make sure the target is a test environment.

Variables and environments

The same test runs against staging, pre-production and, if needed, production; what changes is only the address, the token and a few values. Do not bury them in the requests: make the base address, the token and everything that changes between environments a variable, and keep their values per environment. Postman users know this as collection variables and environments; the same layout works in a load test. Put secrets (tokens, passwords) in the tool's secret store or a pipeline secret, not in the test definition.

With Spitfire

Under Tests → Import API / HAR give the document's URL or upload the file: OpenAPI 3.x, Swagger 2.0 or a Postman collection v2.0/v2.1 (JSON or YAML, up to 10 MB). Operations are listed by tag (by folder in Postman); you search by path, summary or tag and pick. Every operation you pick becomes a step.

• Base URL: one of the document's servers comes selected; you can type your test environment's address instead. It becomes the {{base}} variable in the test.
• Parameters: path parameters become variables ({{orderId}}) with the document's example value; query parameters that are required or have a value in the document come over, and so do required headers. The JSON body is made from the document's example or from the schema.
• Authentication: bearer (OAuth2 and OpenID Connect included) becomes Authorization: Bearer {{token}}, basic auth {{basicAuth}}, an API key in a header or the query {{apiKey}}. These variables come empty; you fill in their values in the editor.
• Postman: the collection's variables become the test's variables, path variables such as :id become {{id}}, and collection and folder auth carries over to the requests. Dynamic variables such as {{$guid}}, {{$timestamp}} and {{$randomInt}} are turned into their Spitfire equivalents; those without one become a fixed sample value. Postman environment files and pre-request and test scripts are not imported; put the environment values on the test's Environments tab.
• Checks and load: every step gets a check for the document's success status code. The test is created as a starting point of 1 VU for 1 minute; you set the load model.

Write requests: only GET requests are selected by default. If POST, PUT/PATCH or DELETE groups are added, each group is confirmed separately and the target host is typed once; the confirmation goes to the audit log with the user, time, IP, the document's SHA-256 and the list of operations. These steps are marked as changing data, and every run of the test asks for write confirmation again before it starts.

openapi: 3.0.3
info: { title: Shop API, version: "1.0" }
servers: [ { url: https://staging.shop.example.com/api } ]
components:
  securitySchemes: { bearerAuth: { type: http, scheme: bearer } }
security: [ { bearerAuth: [] } ]
paths:
  /orders/{orderId}:
    get:
      operationId: getOrder
      summary: Get an order
      parameters:
        - { name: orderId, in: path, required: true,
            schema: { type: string }, example: "o-42" }
      responses: { "200": { description: ok } }

"variables": {
  "base": "https://staging.shop.example.com/api",
  "orderId": "o-42",
  "token": ""
},
"scenarios": [ { "name": "api",
  "executor": { "type": "constant-vus", "vus": 1, "duration": "1m0s" },
  "steps": [ { "id": "getorder", "name": "Get an order", "protocol": "http",
    "request": { "method": "GET", "url": "{{base}}/orders/{{orderId}}",
      "headers": [ { "key": "Authorization", "value": "Bearer {{token}}" } ] },
    "checks": [ { "type": "status", "op": "eq", "value": 200 } ] } ] } ]

Then you complete the test in the editor: extract the token from the login step with JSONPath and bind it to {{token}}, take ids from a CSV data file, add think time and thresholds, and pick the load model. On the Environments tab each environment (staging, production…) gives its own base, token and other values; you pick the environment and scale the load when starting a run or a schedule. From a pipeline: spitfire cloud run "Shop API" --env staging (the CI/CD guide). A HAR file recorded in the browser is imported on the same page; there, tokens and ids are wired from responses to variables automatically. If you have k6 scripts: importing k6 scripts.