Configuration fundamentals

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 and Initial configuration.

Where you configure things in Shift-Left API

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.

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 and Test configuration 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 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 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 — first-time setup, license, users, first project
• Test configuration — environments, variables, headers, datasets
• Project settings — base URL, auth profile, environments
• Public API — for CI/CD integration