Connection Settings: Redirects and Certificates

Overview

Two connection settings, each at the level it describes:

A test that keeps the default stores nothing, so it behaves exactly as it did before these settings existed.

Both settings apply to REST, GraphQL, JSON-RPC and SOAP tests (including fetching a WSDL), wherever the test runs: the Run button, packs and schedules, workflow steps, an endpoint's Try, and the local runner. Explore the capability at Connection settings.

Test a redirect

By default a test follows redirects and checks the final response. To check the redirect itself:

1. Open the test in the test editor.
2. Untick Follow redirects. The test now receives the 3xx response as it is.
3. Add checks on the status (for example 301 or 302) and on the Location header.
4. Save and run the test.

To follow redirects but limit how many, leave Follow redirects ticked and set Maximum redirects. A run that hits the limit fails with an error that names the setting.

Note: Tests that are generated, and run triage, assume a followed redirect. If you untick Follow redirects on a test that expects 200, update its expected status.

Check certificates for a test server

Many test and staging servers use a certificate from a private certificate authority (CA). Two ways to run against them:

• Add a trusted CA certificate (recommended). In Project settings → Environments, open the environment and choose Add trusted CA certificate. Paste the CA certificate (PEM, beginning -----BEGIN CERTIFICATE-----) or load it from a file, then Save certificate. The CA is added to the built-in trusted roots; it never replaces them, so public hosts in the same run still work.
• Turn certificate checking off. Untick Check server certificate for that environment. Use this only for a test server you control.

Some things are refused on purpose:

• Certificate checking is always on for production. An environment counts as production when it is marked as production or when its name says so. Turning checking off is refused when you save, and ignored at run time. Add a trusted CA certificate instead.
• A private key pasted as the CA is refused. The field is for the public CA certificate only.

A client certificate (mTLS) set in an authentication profile keeps working alongside a trusted CA.

When a run fails on a connection

If a run fails because a certificate could not be verified, or because there were too many redirects, the error is a sentence that names the setting to change, on the run's result and in its log, instead of a raw transport error.

Limits

• WebSocket-RPC tests are not covered by these settings.
• The Project Assistant cannot change these settings from chat yet.
• Performance (load) tests do not use these environment certificate settings yet.

Related

• Authentication profiles
• File uploads and form bodies
• Release notes — 21–28 September 2026