Migrate from Postman to DevTools

Name: DevTools
Author: DevTools

Step-by-step guide to migrating from Postman to DevTools. Learn what to migrate vs rebuild, export collections, map variables, and run flows in CI.

Who This Is For

This guide is for teams currently using Postman for API testing who want to:

Move from scripts to flows: Replace JavaScript test scripts with declarative YAML assertions
Get CI-native testing: Run tests with proper exit codes, JUnit/JSON reports, and parallel execution
Source-control everything: Store flows as reviewable YAML files in Git instead of cloud-synced collections
Test from real traffic: Import HAR files from production/staging to build flows that match reality

You don't need to abandon Postman entirely—many teams use DevTools for CI flows while keeping Postman for ad-hoc API exploration.

What to Migrate vs What to Rebuild

Migrate These

Environment variables: Map Postman environments to DevTools {{#env:VAR_NAME}}
Base URLs: Convert {{base_url}} to {{API_BASE}} in environments
Auth secrets: Move API keys/tokens to CI secrets, reference as {{#env:API_KEY}}
Simple request sequences: Export Postman collection, import into Studio as reference

Rebuild from HAR Instead

Script-heavy collections: Pre-request scripts, test scripts, and pm.* logic don't translate—rebuild with DevTools assertions
Anything that drifts from reality: If your Postman collection is outdated vs actual API behavior, record fresh HAR traffic instead
Complex chained requests: Use HAR import to capture real auth flows, token refresh, and request dependencies

Checklist Before You Export Postman

Before exporting collections, prepare your data for CI:

1. Identify secrets → move to CI env vars

Scan your Postman environments for API keys, tokens, and passwords. These should never be in YAML files.

# GitHub Actions example

env:

API_KEY: ${{ secrets.API_KEY }}

LOGIN_PASSWORD: ${{ secrets.LOGIN_PASSWORD }}

2. Identify base URLs → map to API_BASE

Consolidate base URLs into environment variables. DevTools supports {{API_BASE}} or any custom variable.

# DevTools environment YAML

environments:

- name: production

variables:

api: https://api.production.com

- name: staging

variables:

api: https://api.staging.com

3. Identify flaky steps → add assertions at flow level

If certain requests timeout or fail intermittently in Postman, add explicit assertions in DevTools:

response.status == 200
response.body.token != null
response.time < 5000 (for timeout detection)

Step-by-Step Migration

Export Postman Collection

In Postman, click the "..." menu next to your collection → Export → Collection v2.1 (recommended) → Save as JSON.

Install DevTools Studio

Download DevTools Studio for your OS:

https://dev.tools/download

Option A: Import Postman Collection (Reference)

Use the exported JSON as a reference while building flows. Studio doesn't auto-convert Postman collections, but you can manually recreate requests.

Better option: Record fresh HAR traffic from your app (see Option B).

Option B: Record HAR from Real Traffic (Recommended)

Instead of converting Postman collections, capture real API traffic:

Open Chrome DevTools (F12) → Network tab
Perform the API workflow in your app (login, create, fetch, delete)
Right-click network panel → Save all as HAR
Drag HAR file into DevTools Studio

See detailed guide: Generate HAR in Chrome

Map Variables in Studio

DevTools auto-detects tokens and IDs. Review the variable mappings and override if needed.

Example: Map Login.response.body.token to subsequent request headers.

Add Assertions

Convert Postman test scripts to DevTools assertions:

# Postman script

pm.test("Status is 200", () => pm.response.to.have.status(200));

# DevTools assertion

assertions:

- response.status == 200

Export YAML

Export the flow to YAML for version control and CI:

Studio → Export → Save as tests.yaml

Install DevTools CLI

Install the CLI runner for CI:

curl -fsSL https://sh.dev.tools/install.sh | bash

Run Locally First

Test the flow locally before adding to CI:

devtools flow run tests.yaml

Should exit with code 0 (pass) or 1 (fail)

CI Examples

GitHub Actions

name: API Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install DevTools CLI
        run: curl -fsSL https://sh.dev.tools/install.sh | bash

      - name: Run API flows
        env:
          API_KEY: ${{ secrets.API_KEY }}
          LOGIN_EMAIL: ${{ secrets.LOGIN_EMAIL }}
          LOGIN_PASSWORD: ${{ secrets.LOGIN_PASSWORD }}
        run: |
          devtools flow run --report junit:test-results.xml tests.yaml

      - name: Publish test results
        if: always()
        uses: EnricoMi/publish-unit-test-result-action@v2
        with:
          files: test-results.xml

Full template: GitHub Actions Template

GitLab CI

api-tests:
  image: ubuntu:latest
  before_script:
    - curl -fsSL https://sh.dev.tools/install.sh | bash
  script:
    - devtools flow run --report junit:test-results.xml tests.yaml
  artifacts:
    reports:
      junit: test-results.xml
  variables:
    API_KEY: $API_KEY
    LOGIN_EMAIL: $LOGIN_EMAIL
    LOGIN_PASSWORD: $LOGIN_PASSWORD

Full template: GitLab CI Template

Common Problems

My Postman collection has pre-request scripts. How do I convert them?

DevTools doesn't support JavaScript scripts. Instead:

For variable setting: Use DevTools variable mapping (e.g., {{Login.response.body.token}})
For auth flows: Capture the real flow in a HAR file and let DevTools auto-map the tokens
For complex logic: Move it to your application code or use environment variables

Variables aren't being replaced in my requests

Check these common issues:

Syntax: DevTools uses {{varname}} not {{varname}}
Environment secrets: Use {{#env:SECRET}} for CI variables
Response references: Use {{StepName.response.body.field}}
Environment not selected: Make sure you're running with the correct environment

Tests pass in Postman but fail in DevTools CLI

Common causes:

Missing environment variables: Make sure all secrets are in CI env vars
Parallel execution: DevTools runs flows in parallel by default. Use --sequential if order matters
Timing issues: Add explicit waits or retry logic for flaky endpoints
Base URL mismatch: Verify {{api}} points to the right environment

How do I handle dynamic data (timestamps, random IDs)?

Use assertions that check types instead of exact values:

# Instead of exact match

response.body.id == "12345"

# Check existence/type

response.body.id != null

response.body.createdAt != null

Can I import Newman test results for comparison?

Both Newman and DevTools CLI support JUnit/JSON output. You can:

Run both in parallel initially to compare results
Use the same CI test result parsers (JUnit XML)
Gradually migrate flows one at a time while keeping Newman for the rest

Frequently Asked Questions

Do I need to stop using Postman entirely?

No. Many teams use Postman for ad-hoc API exploration and DevTools for CI testing. You can run both in parallel during migration.

Can DevTools import Postman collections directly?

Not automatically. We recommend recording fresh HAR traffic instead, which ensures your flows match current API behavior. Postman collections often drift from reality over time.

What happens to my Postman test scripts?

DevTools uses declarative assertions (response.status == 200) instead of JavaScript. Most Postman scripts can be converted to assertions or variable mappings.

How long does migration take?

For simple collections (5-10 requests), expect 30-60 minutes. For complex collections with scripts and environments, allow 2-4 hours. Recording fresh HAR traffic is often faster than converting old collections.

Does DevTools support Postman monitors?

DevTools doesn't have built-in scheduling. Instead, use CI cron jobs (GitHub Actions scheduled workflows, GitLab CI schedules) to run flows on a schedule.

Can I share flows with my team like Postman workspaces?

Yes, but differently. DevTools flows are YAML files in Git. Share them via pull requests, code review, and version control—the same way you share application code.

What about Postman mock servers?

DevTools focuses on testing real APIs, not mocking. If you need mocks, keep using Postman mock servers or use tools like WireMock/MSW alongside DevTools.

Ready to migrate?

Download DevTools Studio and start building flows from real traffic.

Download Studio Install CLI