Release notes — September 2026 (21–28 September)

Summary

Shift-Left Studio now load tests your APIs. Performance testing is built from the functional tests you already have, so the same authentication, headers and bodies go out under load, and the report leads with a verdict in words before any chart. Performance targets can be linked to requirements and show in the traceability matrix under load. Authentication catches up with the way real APIs sign in: OAuth 2.0 works the way Postman users expect, NTLM, JWT Bearer signing, Hawk and OAuth 1.0a options arrive, a multi-step sign-in covers one-time codes, and a Postman collection's auth now imports into profiles. REST tests can send multipart uploads, url-encoded forms and whole-file bodies. See API load testing for an overview.

Improvements

Performance testing

• Performance testing, built from your tests. Pick tests or a workflow, choose how much traffic, set your targets and run. Start from the designer, from a test with Run as load test, or from a pack with Create load scenario from this pack. Every request is built by the same code a functional run uses; values saved by one step feed the next, and a bound data set gives each virtual user different values. REST, SOAP, GraphQL and JSON-RPC tests can be used. See Performance testing overview.
• Nine kinds of test. Smoke, load, stress, spike, soak, breakpoint, concurrency, rate-limit probe and custom, each with a starting profile you can change. Load, soak and concurrency hold a number of virtual users; stress, spike, breakpoint and rate-limit tests hold a request rate, so a slowing API cannot quietly receive less traffic.
• A dry run and built-in safety. The dry run builds the exact plan and sends nothing. You confirm once per project that you are authorised to send load; production is refused unless an Administrator allows it, and then its name must be typed. One request per step is sent as a precheck, and a run stops itself if more than half its requests fail for ten seconds.
• A report that leads with the verdict. Anything that limits what the run proves comes first (such as an overloaded load generator, which makes the verdict Inconclusive), then Pass, Fail, Inconclusive or No verdict with the reason. Runs are judged on the steady stage only, percentiles come from merged histograms and are never averaged, and each step's time is split into connection wait, DNS, connect, TLS, time to first byte and download.
• Why a load run failed. Every cause is listed, grouped by where to look, with how many requests it affected, when it began and the load at that moment, what the server said, and what to do next. A run log lists what happened in order.
• Run history by cause. All runs and why they failed lists every performance run of a project, and Why runs failed counts each cause across runs. Performance runs also appear on the Reports tab under Performance runs, and are kept out of functional pass-rate summaries.
• Baselines and comparison. Pin a run as the baseline; later runs are compared with a statistical test over every interval's p95, so a change within normal variation is not called a regression. Compare two runs side by side, or see a scenario's trend.
• Performance targets (SLOs). Keep targets under Project settings. They are judged continuously on functional runs of the endpoint and inside load tests that attach them. A target linked to a requirement shows met or missed in the requirements matrix's new Under load column, beside the functional verdict. See Performance reports and targets.
• Load agents (Trial and Enterprise). Split a run across other machines, the local runner in agent mode or the Engine. Agents connect out to the server; each takes an equal share of users, rate and data rows; all start together; and measurements are merged exactly. A lost, late or overloaded agent is named in the report.
• Share, export, schedule and CI. Export HTML, JSON, JUnit XML or CSV; share a read-only link that expires; schedule a scenario with email, Slack, Teams or webhook notifications; and start runs from CI with an API key via POST /api/performance/scenarios/{scenarioId}/run.
• The assistant explains a run. The Project Assistant can explain a performance report in plain language, starting with any warning about the load generator, and can offer to create a scenario, start a run, create a target or pin a baseline once you accept. AI agents connected through the MCP server can read load runs but cannot start one.
• Editions. Professional: up to 100 virtual users per load generator, 15-minute runs, one run at a time. Trial and Enterprise: up to 2,000 per load generator, 12-hour runs, two at a time, and load agents. The free Citizen Developer edition shows a preview.

Authentication

• OAuth 2.0, the Postman way. Every grant type (Authorization Code with PKCE, Device Code, Client Credentials, Password and Implicit) with Get New Access Token. Use the Callback URL you already registered, including Postman's, or tick Authorize using browser to use Studio's own; the Desktop app catches the redirect in its own sign-in window. Fill in for a provider pre-fills Microsoft Entra ID, Okta, Auth0, Keycloak and Google, and runs refresh the token themselves. See OAuth 2.0 sign-in.
• More methods. NTLM (NTLMv2) is new. JWT Bearer can sign a fresh token for every request (HS, RS, PS and ES algorithms) or send a pasted one. Hawk gains payload hash, ext, app and dlg; OAuth 1.0a gains HMAC-SHA512 and RSA signing, callback, verifier, realm and body hash. API Key + Bearer sends the key alongside the token on every request.
• Sign in with steps. For APIs whose sign-in takes several requests (a login, a one-time code, a token exchange and a custom refresh), chain the steps once and store the password encrypted. See Sign in with steps.
• Every method applies on every run. Tests, packs, workflows, schedules, load tests and the desktop Agent all authenticate through the profile.
• Postman auth imports into profiles. API Key, Basic, Bearer, Digest, NTLM, Hawk, JWT Bearer, OAuth 1.0 and OAuth 2.0 (including PKCE and the advanced parameters) are mapped, and collection and folder auth is inherited by requests exactly as in Postman. See Postman collection import.
• Configure authentication from chat. Ask the Project Assistant to set up a profile of any supported method, or paste a Postman-style setup; it prepares the profile and asks you for the secrets itself rather than handling them.

Requests and connections

• File uploads and form bodies. A REST test's body can be application/x-www-form-urlencoded, multipart/form-data with file parts, or a whole file. The same bytes are sent on the Run button, packs and schedules, workflows, data-driven iterations, load tests and the desktop Agent. Form-only OpenAPI endpoints and Postman form and file bodies import correctly. See File uploads and form bodies.
• Test file storage. Uploaded test files count toward a per-project quota, and files no test uses are cleaned up after a grace period.
• Follow redirects, per test. Follow redirects (the default) or return the 3xx as it is, so a test can check a redirect's status and Location header.
• Certificate checking, per environment. Turn certificate checking off for a test server, or add a trusted CA to the built-in roots. Checking can never be turned off for production. A certificate or too-many-redirects failure now names the setting to change.

Sharing and sign-in

• Share links from the Desktop app. An administrator can set the installation's Public Address under Settings. When a link cannot travel, the Share dialog offers the HTML report and a link that opens the dashboard in Shift-Left Studio.
• One licensed session per user. Signing in on another machine ends the earlier session, and the login screen says why.
• Header section buttons show which section is open, and sections open on the current project.

Fixes

• Authentication: API Key + Bearer, Load Sample, cookie login URL matching and Digest now behave as documented; a workflow-opened test uses the right authentication profile; and Desktop Agent runs no longer fail with 401.
• Execution: a bodiless REST test no longer sends a Content-Type header; a GET no longer sends a request body; and sub-second runs no longer report 0 ms.
• Data-driven tests: {{row.*}} tokens resolve in a data-driven step's assertions, and sheet columns bind only to fields the request has.
• Test editor: removing a body parameter removes its key from the JSON body.
• Change detection: the monitored URL is editable, and approving an import removes endpoints the specification dropped.
• Performance and analytics: a scenario keeps its user count, and Print exports the report.
• Workflows: the step popup shows the step's result.
• Desktop: Ctrl+= zooms in, and the test level shows the real Agent version.
• Interface: project settings open fresh, deleted features leave the sidebar, and duplicate Select All buttons were removed from the Workflows page and the project feature table.

Known issues

• WebSocket-RPC calls and MCP server endpoints cannot be load-tested; each needs a held session per user.
• Under load, values are not read out of SOAP responses between steps; the report warns when a test relies on that.
• A scenario that authenticates with a client certificate runs from the server only, not from load agents.
• Akamai EdgeGrid, ASAP and AWS Signature auth in a Postman collection are not mapped into profiles yet.
• The desktop Agent must be updated to this release to receive the authentication and execution fixes above.

Related links

• API load testing overview
• Performance testing documentation
• Authentication profiles
• Plans and editions