Roadmap

This page shares the features we are planning, exploring, or considering for future versions of Curlex. Nothing here is a committed release schedule — it is a transparent look at what is on our radar.

Sending Requests

Proxy Support

Right now, Curlex sends requests directly from your machine. If you work behind a corporate HTTP or HTTPS proxy — common in enterprise environments — Curlex requests cannot get through.

We plan to add proxy configuration in Settings → General: specify your proxy address, port, and optional credentials. You will also be able to detect and use the system proxy automatically, and override the proxy on a per-request basis.

This is one of the most-requested missing features from users in corporate environments.

General WebSocket Connections

Curlex currently supports WebSocket only for GraphQL subscriptions. We plan to add a dedicated WebSocket request type for general-purpose WebSocket APIs — the kind used by chat applications, real-time dashboards, and event streaming systems.

This would include:

• A connect/disconnect interface with a live status indicator
• A message panel for sending text or binary frames
• A scrolling log of incoming messages
• The ability to include custom headers in the upgrade handshake

Authentication

Digest Authentication

Digest Auth is an older but still widely used authentication scheme — particularly common in legacy enterprise systems, some embedded device APIs, and WebDAV servers. Adding it requires handling a two-round-trip challenge-response flow where the server sends a nonce and the client responds with a cryptographic hash.

AWS Signature v4

Teams calling AWS APIs directly — API Gateway endpoints, S3, DynamoDB, or any other AWS service — need AWS Signature v4 signing. Curlex would handle the canonical request construction, signing key derivation, and injecting the required Authorization, x-amz-date, and optionally x-amz-security-token headers automatically.

You would fill in your Access Key ID, Secret Access Key, AWS Region, and Service name — the rest happens behind the scenes.

NTLM Authentication

NTLM is required for calling APIs protected by Windows Active Directory or Azure AD in some configurations. It involves a multi-step handshake and is tricky to implement correctly — this requires a native Rust implementation in the Tauri backend.

Scripting

Collection-Level and Folder-Level Scripts

Currently, pre-request and test scripts can only be attached to individual requests. We plan to add scripts at the collection and folder level as well.

This unlocks patterns like:

• A collection-level pre-request script that logs in and sets {{authToken}} before any request runs — instead of putting this in every individual request.
• A folder-level pre-request script that sets up state specific to that group of endpoints.
• A collection-level test script that checks a common condition (like "no internal server errors") after every request.

Scripts would execute in a chain: collection → folder → request (pre-request), then the reverse order (test scripts).

More Libraries Available in Scripts

Script sandboxes currently have access to basic JavaScript. We plan to make a curated set of popular libraries available inside scripts — things like lodash (data manipulation), uuid (ID generation), crypto-js (hashing and encryption), and ajv (JSON Schema validation).

This would let you write more powerful test scripts without having to implement common operations from scratch.

Visual Test Builder

Writing JavaScript is not for everyone. A visual test builder would let you construct assertions by choosing from dropdowns — pick a field from the response, pick an operator (equals, contains, is greater than, etc.), and type the expected value. Curlex would generate the test code automatically.

Importing More Formats

Insomnia Collections

Insomnia is another popular API client with a large user base. We plan to add an importer for Insomnia v4 collections so teams switching from Insomnia can bring their requests across without rebuilding them manually.

WSDL and SOAP

Some enterprise and government APIs still use SOAP and WSDL. We plan to add basic WSDL import — parse the WSDL file and generate SOAP request stubs in a collection, pre-filled with the right XML envelope structure.

Security

Connecting to External Secret Managers

For teams that use a centralised secret manager, we plan to add integrations so that variable values can be fetched from:

• AWS Secrets Manager
• Azure Key Vault
• HashiCorp Vault

You would reference secrets with a syntax like {{aws:my-api-key}}, and Curlex would fetch the real value at request time. The value is never stored in your collection or Git history — it is fetched fresh each time.

Future Explorations

AI-Assisted Request Generation

Describe what you want to test in plain language — "create a POST request to register a new user with email, password, and name fields" — and have Curlex generate the request structure, example body, and suggested test assertions automatically.

We could also use this to help write test scripts: point it at a response and ask it to generate assertions that verify the key fields.

Response Diffing

When you run the same collection before and after a code change, it would be useful to see exactly what changed in the responses — which fields appeared, disappeared, or changed value. A side-by-side diff view could surface regressions that are invisible when looking at individual responses in isolation.

API Schema Visualization

For collections built from OpenAPI specs, a visual diagram of the API structure — showing endpoints, their relationships, request parameters, and response types — would make it much easier to understand a large API at a glance.

CLI Runner

A command-line tool — curlex run — would let you run a Curlex collection directly from a terminal or CI pipeline, without opening the desktop app.

curlex run my-collection.json \
  --env staging.json \
  --data test-cases.csv \
  --reporter junit \
  --output results.xml

This would output JUnit XML, HTML, or JSON reports compatible with Jenkins, GitHub Actions, and other CI systems. It is the feature that would let Curlex fit natively into automated deployment workflows.

Not Currently Planned

Some things are out of scope for now: