Import Export and Git Workspace

Import / Export and Git Workspace

Several ways to get data in and out of Getman: import from an OpenAPI / Swagger spec, Postman import, Postman export, and a git-friendly workspace mirror.

OpenAPI / Swagger import

Turn an existing API specification into a ready-to-use collection in seconds — the fastest way to migrate from another client.

Supported: OpenAPI 3.0 / 3.1 and Swagger 2.0, as JSON or YAML. (HAR capture import isn't supported yet.)

Open it: in the COLLECTIONS tab, open the IMPORT (upload) menu and choose FROM OPENAPI / SWAGGER. The IMPORT API SPEC dialog offers three sources:

• FILE — pick a .json, .yaml, or .yml file (PICK FILE).
• PASTE — paste the raw spec text and press PARSE.
• URL — enter a remote spec URL (e.g. https://api.example.com/openapi.json) and press FETCH.

Preview & select: once the spec parses, you get a checkbox tree of folders → requests. Untick anything you don't want; ticking/unticking a folder toggles all its requests. A summary line shows how many environments will be created. Use LOAD ANOTHER to start over, IMPORT to commit, or CANCEL to discard.

What gets created:

• One collection named after the spec's title. Requests are grouped into folders by tag; operations with no tag are grouped by their first path segment.
• One environment per declared server, each with a {{baseUrl}} variable; every request URL is templated as {{baseUrl}}/path. Switch the active environment to point the whole import at dev / staging / prod. See Environments and Variables.
• Path parameters like /users/{id} become {{id}} tokens.
• Query/header params and JSON bodies are pre-filled from the spec's example/default values, or a small stub generated from the schema.
• Auth: the auth type (Bearer / Basic / API key) is set from the spec's security, with the secret value left blank and a labeled secret variable seeded into each environment for you to fill in. OAuth2 / OpenID schemes are recognized but left as None for now (a note appears after import). See Authentication.
• Imported nodes get fresh IDs, so they never collide with what you already have.

Postman import

Bring in existing Postman v2.1 collections and environments.

• Collections: in the COLLECTIONS tab, open the IMPORT (upload) menu and choose FROM POSTMAN, then pick one or more .json files. Each file is parsed and added; failures are reported per file.
• Environments: import Postman environment exports the same way (single object or an array).
• Imported nodes get fresh IDs, so they never collide with what you already have.
• Body types are preserved: raw, urlencoded, formdata (multipart, including file rows), and file (binary).
• Only Postman v2.1 schema is accepted; malformed files are rejected with a clear error.

Postman export

• A collection or request: from a node's menu, choose EXPORT TO POSTMAN. You get a *.postman_collection.json (schema v2.1) you can hand to anyone using Postman.
• Environments: export a single environment or all of them.
• Secret variables are masked on export (empty value, type: "secret"). See Environments and Variables.
• Saved examples are not exported — they're a local convenience that carries captured response data. See Collections.

Git-friendly workspace (desktop)

Mirror a collection to a folder of readable JSON files you can commit and review in pull requests.

What it is

• Hive is the source of truth while the app runs; the workspace folder is a mirror.
• On open, the folder is read into Getman. During the session, every change is written back out (debounced, so a burst of edits is one write).
• It's best-effort — write failures are logged, never crash your session.

Layout

Each request is a *.req.json file; each folder is a directory with a .folder.json (name, favorite, child order); a .getman/workspace.json records the root order. Names are slugified into stable, collision-free filenames.

What's omitted (on purpose)

• Response data (body/headers/status/duration) — to avoid leaking responses into git and creating churny diffs.
• Saved examples — same reason; they're local-only.

So the committed files describe requests and structure, not captured responses — clean diffs your team can review.

Using it

1. Configure the workspace folder under Settings → COLLECTIONS → Workspace settings (desktop).
2. Commit the folder (including .getman/) to git.
3. Teammates pull, open the same folder, and Getman loads the collections.
4. You can hand-edit the JSON files and reload the workspace to pick up changes.

Which should I use?

• Share with Postman users / one-off handoff: Postman export.
• Version-control collections with your team / review in PRs: git workspace.
• Move quickly between machines you own: either works; the workspace keeps history in git.