# Configuration fundamentals

> Where to configure base URL, authentication, and environment variables in Shift-Left API so test runs are stable and CI-ready.

Source: https://totalshiftleft.ai/help-center/configuration/environment-variables


## Overview

In Shift-Left API, you configure **where** your tests run (base URL, environments) and **how** they authenticate (API key, Bearer token, headers) in **Project settings** and **Test configuration**. This keeps test runs stable, repeatable, and CI-ready without hardcoding URLs or secrets in tests.

If you haven’t completed installation or initial setup yet, start with [Getting started](/help-center/installation/getting-started) and [Initial configuration](/help-center/configuration/initial-configuration).

## Where you configure things in Shift-Left API

| What you need | Where in Shift-Left API |
|---------------|-------------------------|
| Base URL per environment (Dev, Stage, Prod) | [Project settings](/help-center/product-documentation/project-settings) → Environment setting / Base URL by environment |
| Headers (API key, auth, custom headers) | Project settings → Project-level headers, or [Test configuration](/help-center/product-documentation/test-config) → headers |
| Auth (API key, Bearer, Basic) | Project settings → Authentication profile |
| Variables and datasets for test runs | [Test configuration](/help-center/product-documentation/test-config) (environments, global variables, datasets) |
| How Studio talks to the Engine (URL, proxy) | [Server Connection](/help-center/product-documentation/server-connection), [Proxy Settings](/help-center/product-documentation/proxy-settings) |

## Execution mode and environment behavior

Execution mode affects where the same environment configuration is executed:

- **Shift-Left Engine** runs on server infrastructure and is best for CI/CD and scheduled runs.
- **Shift-Left Agent** runs locally and is best for development workflows and private/internal API access.

Regardless of mode, keep base URL, auth profile, and variables consistent so results are comparable across local and server execution.

For mode selection and agent availability states, see [Execution mode](/help-center/product-documentation/execution-mode).

## Base URL and environments

- Define one **base URL per environment** (e.g. Dev, QA, Staging, Prod) in your project so tests hit the right API.
- Use stable hostnames (avoid per-developer or ephemeral URLs) so runs are consistent.
- Keep dev and stage separate so failures are easier to interpret.

See [Project settings](/help-center/product-documentation/project-settings) and [Test configuration](/help-center/product-documentation/test-config) for step-by-step setup.

## Authentication

Configure auth so test requests are authorized in the target environment:

- **API key**: Add as a header (e.g. `x-api-key`) or query parameter in project headers or test configuration. Store the key securely; do not commit it to source control.
- **Bearer token (OAuth/JWT)**: Use `Authorization: Bearer <token>`. Ensure the token has the right scopes for the endpoints under test. In CI, refresh short-lived tokens as needed.
- **Basic auth**: Use a dedicated test account with least privilege; configure via project or test configuration.

Create and attach **authentication profiles** in [Project settings](/help-center/product-documentation/project-settings) so the project (or specific environments) use consistent credentials.

## Timeouts and retries

- Set a reasonable **request timeout** (e.g. 10–30 seconds) where the product allows it so slow endpoints don’t cause false failures.
- Use **retries** only for transient issues (timeouts, 502/503), not for stable 4xx responses.

Check [Test configuration](/help-center/product-documentation/test-config) and run settings for timeout and retry options.

## Security and secrets

- Do **not** commit API keys, tokens, or passwords to repositories. Configure them in Shift-Left API (project or test configuration) or inject them at runtime (e.g. from your CI secret store).
- Prefer **least privilege**: use tokens and accounts that only have access to what tests need.
- Rotate keys and tokens periodically.

## Common issues

- **401/403 on test runs**: Token or API key missing, expired, or wrong scope. Check auth profile and headers in Project settings / Test configuration.
- **404 for valid endpoints**: Base URL or path doesn’t match the API. Confirm the environment base URL and the spec’s `servers`/paths.
- **Tests pass in Studio but fail in CI**: CI might use different env vars or secrets. Ensure the same configuration (or overrides) are available in your CI pipeline.

## What to read next

- [Initial configuration](/help-center/configuration/initial-configuration) — first-time setup, license, users, first project
- [Test configuration](/help-center/product-documentation/test-config) — environments, variables, headers, datasets
- [Project settings](/help-center/product-documentation/project-settings) — base URL, auth profile, environments
- [Public API](/help-center/product-documentation/public-api) — for CI/CD integration