Platform Overview: How Shift-Left API Works
A map of the platform: the project/feature/endpoint tree, the Execution, Reporting, Analytics, Mocks and Workflows areas, and the path from spec to results.
Overview
Shift-Left API is a spec-first API test automation platform. It takes an API contract — an OpenAPI or Swagger document — and turns it into organized endpoints, runnable tests, scheduled executions, and traceable reports, without requiring you to write test code.
This page is a map. It explains how the product is organized and where each task lives, so you know which article to read next.
Supported protocols are REST, SOAP, and GraphQL.
How work is organized
Your test assets live in a three-level tree in the left sidebar:
| Level | What it is |
|---|---|
| Project | The top-level container, usually one API or service domain. Holds its own settings, environments, and credentials. |
| Feature | A grouping inside a project, used to organize endpoints by area of functionality. |
| Endpoint | A single operation (for example GET /orders/{id}), imported from your spec or added by hand. Tests hang off endpoints. |
Alongside the tree you'll also find integration tests, which chain multiple endpoints together rather than testing one in isolation.
The main areas
The top navigation gives you the working areas of the product:
| Area | What you do there |
|---|---|
| Execution | Create, run, and schedule Test Run Packs. See Test Execution. |
| Reporting | Review run outcomes with request/response evidence. See Test reporting. |
| Analytics & Dashboards | Trends and quality metrics over time. See Understanding analytics. |
| Mocks | Stand in for services that aren't available yet. See Understanding mocks. |
| Workflows | Multi-step sequences executed end to end. See Understanding workflows. |
| Platform Settings | Users, permissions, licence, integrations, and system configuration. See Administration settings. |
| Help & Version Information | Build and version details. See Help & version information. |
Analytics & Dashboards requires a Pro, Trial, or Enterprise plan.
The core path
The typical journey from contract to results:
- Create a project for the API domain — Project.
- Import endpoints from your OpenAPI/Swagger spec — Endpoint import and discovery. Discovery reads the spec and creates the endpoints for you.
- Configure the environment and auth so requests can actually reach your API — Project settings and Test config.
- Create tests. Author them by hand with Test case, or generate them with AI-generated tests.
- Run them. A single Test run while iterating, or a Test run pack for a repeatable, schedulable group.
- Review results — High level test report for the summary, Detailed test report for per-test evidence.
Steps 1–3 are one-time setup per project. Steps 4–6 are the loop you'll live in.
Where tests run
Tests execute in one of two places, and the execution mode you choose decides which:
| Runner | Where it runs | When to use it |
|---|---|---|
| Shift-Left Engine | Server-side, on the platform | The default. Use it whenever your API is reachable from the platform. Applies to both scheduled and manual runs on the server. |
| Shift-Left Agent | Locally, on your own machine or build agent (localhost:5004 by default) | Use it when your API isn't reachable from the internet — a local environment, or a service behind a corporate network. |
Each runner has its own settings, including separate proxy configuration per execution mode. Reports show which runner produced a result, so you can always tell whether a run went through the Engine or the Agent.
See Execution mode and Local runner.
Reading results
Runs report four canonical statuses, and the difference between the middle two is the one worth learning:
| Status | Meaning |
|---|---|
| Passed | The test succeeded. |
| Failed | Your API responded, but the response didn't match expectations. |
| Error | The request couldn't complete at all — unreachable host, TLS, timeout. |
| Not run | The test was skipped. |
Failed points you at your API or your assertions. Error points you at connectivity or configuration. Triage Error first — transport problems cascade and generate failures that aren't real.
Recommended first path
If you're just starting:
- Getting started — install and sign in.
- Initial configuration — get the system ready.
- Configuration fundamentals — set up environments.
- Create a project, import a spec, and run your first pack.
Related articles
Next steps
- Getting started · Install + connect your spec
- Configuration fundamentals · Stabilize runs
- Initial configuration · Users, licensing, projects
- Release notes · Updates and fixes
Still stuck?
Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.