Importing and Migrating

Curlex can import requests and collections from four sources: Postman, cURL commands, OpenAPI/Swagger specifications, and previously exported Curlex files. You do not need to rebuild your work from scratch.

This page covers what each importer supports, what to watch for, and a step-by-step migration guide specifically for Postman users.

How to Import

Click Import in the header bar at the top of the window. A dialog opens where you can either:

• Drag and drop a file onto the dialog, or
• Click to browse for a .json, .yaml, or .yml file, or
• Paste text directly into the input area — useful for pasting a cURL command copied from a terminal or documentation page.

Curlex detects the format automatically. If detection fails or you want to override it, click one of the format chips (OpenAPI, Postman, cURL, Curlex) to choose manually.

Importing from Postman

Curlex reads Postman Collection v2.1 exports and preserves as much of your work as possible.

Step 1 — Export from Postman

1. In Postman, open the collection you want to export.
2. Click the … (three dots) menu on the collection.
3. Choose Export.
4. Select Collection v2.1 as the format.
5. Click Export and save the .json file to your computer.

To export environments:

1. Click the Environments icon in Postman's sidebar.
2. Click the … menu on each environment and choose Export.
3. Each environment exports as a separate .json file.

Step 2 — Import into Curlex

1. Click Import in Curlex's header bar.
2. Select your Postman collection .json file. Curlex auto-detects the Postman format.
3. Click Import.
4. To import environments, repeat: Import → select the environment .json file. Curlex recognises Postman environment exports too.

What Transfers Across

What to Check After Importing

Scripts using pm.* — these work without changes. Curlex supports pm as a full alias for its own fc scripting API. pm.test(), pm.expect(), pm.environment.get(), pm.response, and all other pm.* calls run exactly as written. You do not need to rewrite any scripts.

OAuth 2.0 — Postman embeds the obtained token in the export, not the flow configuration. After importing, you may need to re-enter your OAuth 2.0 flow settings (Client ID, Client Secret, Auth URL, Token URL) to be able to refresh tokens. The bearer token itself is imported and will work immediately, but will not auto-refresh without the flow config.

GraphQL requests — Postman GraphQL bodies import as raw JSON. You can manually switch the body type to GraphQL in Curlex's body type selector to get the dedicated query editor, schema introspection, and autocomplete.

File uploads — form-data file fields note the original filename but do not embed the actual file (Postman does not include file contents in exports). Re-attach any files to those fields.

Digest, NTLM, and AWS Signature auth — Curlex does not yet support these auth types. Requests using them import without auth configured. You can work around this by constructing the auth header manually in the Headers tab.

Importing from cURL

Paste any curl command and Curlex creates a ready-to-send request from it instantly. This is the fastest way to import requests from API documentation, browser DevTools, or terminal history.

How to Use It

1. Click Import → paste your cURL command into the text area.
2. Curlex auto-detects the curl format.
3. Edit the Request Name (auto-suggested from the URL).
4. Choose a Target Collection to add it to, or leave it to create a standalone request.
5. Click Import.

Supported curl Flags

Method:

Headers:

Multiple -H flags are supported — each becomes a separate header row.

Request Body:

Authentication:

URL and Query Parameters: Query parameters in the URL (?key=value&key2=value2) are automatically split into individual rows in the Params tab.

What cURL Import Does Not Parse

The following flags are accepted by curl but ignored during import — you may need to set these manually in Curlex:

• --cert, --cacert, --key — TLS certificates (configure in Settings → Certificates)
• --proxy, --socks5 — Proxy settings (not yet supported in Curlex)
• -A / --user-agent — Parsed as a regular header
• --cookie-jar — Cookie file handling
• -o, -O — Output file (not applicable in Curlex)
• Timeout flags (--connect-timeout, --max-time)
• Resolver overrides (--resolve)

Importing from OpenAPI / Swagger

Curlex can generate a complete collection from any OpenAPI 3.x or Swagger 2.0 specification file. Each endpoint in the spec becomes a request, pre-populated with the correct method, URL, parameters, headers, and example body.

Supported Specification Versions

How to Import

1. Click Import and select your .json, .yaml, or .yml spec file.
2. Curlex detects the OpenAPI/Swagger format automatically.
3. Two options appear before you confirm:

Request Naming — how each request gets its name:

• URL path (default) — uses the endpoint path, e.g. /users/{id}
• Summary / operationId — uses the summary, operationId, or description field from the spec if available, falling back to the URL path

Folder Organisation — how requests are grouped:

• Flat (default) — all requests in a single flat collection
• By path segments — the first segment of each path becomes a folder (e.g. /users/... → "users" folder)
• By tags — the first tag on each operation becomes a folder, matching how Swagger UI organises endpoints

4. Click Import.

What Gets Imported

Endpoints: Every operation (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS, TRACE) across all paths.

Parameters:

• Path parameters (/users/{id}) — added as part of the URL with placeholder values
• Query parameters — added to the Params tab
• Header parameters — added to the Headers tab
• Examples and default values from the spec are used as initial values

Request Bodies:

• Body content from requestBody (OpenAPI 3) or body parameters (Swagger 2)
• JSON examples from the spec are placed in the body editor
• Content type is detected from the spec's media type (application/json, application/x-www-form-urlencoded, multipart/form-data)

Authentication: Security schemes from the spec are converted to Curlex auth settings:

• oauth2 → Bearer Token placeholder
• http: bearer → Bearer Token placeholder
• http: basic → Basic Auth placeholder
• apiKey (header or query) → API Key auth with the correct placement

Grouping: Operations grouped by tags (when tag grouping is selected) or by first path segment.

What Is Not Imported:

• Callbacks and webhooks
• Server variables in URL templates
• Remote $ref references (only local #/ references are resolved)
• Non-JSON request/response examples
• Response schema (response bodies are not pre-populated — the spec is used to generate the requests, not mock the responses)

Importing a Curlex Collection

To import a collection that was previously exported from Curlex:

1. Click Import and select the .json export file.
2. Curlex detects the Curlex format.
3. Choose a Target Collection to merge the import into, or leave it blank to create a new standalone collection.
4. Click Import.

This also works for individual folder exports and individual request exports.

Exporting from Curlex

Exporting a Collection

Right-click any collection in the sidebar and choose Export. A .json file is downloaded containing the full collection: all folders, requests, auth settings, variables, and scripts.

Secret variable values are blanked in exports — the variable keys are present but the values are replaced with empty strings. This means you can safely share a collection export without exposing credentials.

Exporting a Folder or Single Request

Right-click any folder or request and choose Export. The export includes the item and everything inside it, plus the collection variables that the requests reference.

Exporting an Environment

Open Environments, right-click an environment, and choose Export. As with collections, secret variable values are blanked.

Exporting as OpenAPI

Curlex can generate an OpenAPI specification from a collection:

1. Right-click a collection and choose Export as OpenAPI.
2. Choose the version: OAS 2.0, OAS 3.0, or OAS 3.1.
3. Choose the format: JSON or YAML.

The generated spec includes all endpoints, methods, parameters, headers, and request body schemas inferred from your requests.

Migrating from Postman — Complete Checklist

If you are moving your full Postman workspace to Curlex, here is a step-by-step checklist:

Before You Start

• Identify all collections to migrate (check every Postman workspace)
• Note any collections that use Digest, NTLM, or AWS Signature auth — these need manual attention after import
• Note any collections that use GraphQL body types — you can switch them to Curlex's native GraphQL editor after import
• Export all environments you use

Exporting from Postman

• For each collection: Export → Collection v2.1 → Export
• For each environment: Environments → … → Export
• Save all files to a folder (e.g. postman-export/)

Importing into Curlex

• Create a new workspace in Curlex if you want to keep Postman work separate
• Import each collection file: Import → select file → Import
• Import each environment file: Import → select file → Import
• Verify collections and folders appear correctly in the sidebar

After Importing

• Scripts: Run a few requests with pre-request or test scripts to confirm they execute. Scripts using pm.* run unchanged — no rewriting needed.
• Environments: Open each environment and verify variables came across. Re-enter any secret values that were blanked during export.
• OAuth 2.0: Re-enter OAuth 2.0 flow configuration (Client ID, Client Secret, URLs) for any requests that use it. The imported bearer token works immediately but cannot be refreshed without the flow config.
• Collection Runner: If you have Postman test suites, run the equivalent collection in Curlex's Collection Runner to verify test assertions pass.
• Unsupported auth types: For any request that used Digest, NTLM, or AWS Signature auth, add the equivalent header manually in the Headers tab or note it as a workaround until Curlex adds native support.

What You Gain After Moving

• No cloud account or mandatory sync
• ~15 MB app vs ~400 MB
• Native OS keychain for token storage (via the Vault)
• PDF test run reports
• TLS certificate chain details in responses
• Redirect chain visualization
• All your pm.* scripts continue to work