Overview

API mocks let you create and manage fake responses for your API endpoints. In Shift Left Studio you can use them two ways:

During test execution, so tests don't depend on live services.
As a standalone mock server, so clients, tools, or teammates can call predictable responses outside a full test run.

Mocks are always scoped to a project — you pick a project on the API Mocks page, then create and manage mocks for that project's endpoints. This article covers what mocks are and how they behave. Explore the capability at mock server.

Before you begin

This is a conceptual overview. For the click-by-click UI walkthrough — creating, generating, configuring, and serving mocks — see Creating and configuring mocks.
Open mocks from the top navigation Mocks entry, then choose a project from Select a project. Use All Projects to switch projects later.
Linking mocks to endpoints (or bulk-generating them) requires a project with at least one endpoint; see Endpoint management.

The high-level flow

Select a project — pick a project on the API Mocks page to manage its mocks.
Create or generate mocks — add mocks by hand with Create Mock, or bulk-create them from endpoint schemas with Generate Mock.
Start the server — click Start Mock Server to serve active mocks; Stop Server ends it (the header shows "Mock server running" while active).
Test and use — try responses with a sample request, then use mocks in test execution or via the standalone server.

Mock capabilities

Capability	What it gives you
Static and dynamic responses	Fixed JSON/XML payloads, or dynamic templates with variables resolved at request time.
Multiple responses + conditions	One mock can hold several named responses, each guarded by conditions on the request; a Default Response is returned when nothing matches.
Latency simulation	Per-response Delay (ms) to exercise timeouts and slow paths.
Standalone server	Run mocks as a server for external testing or integrations, via a path-based or subdomain URL.
Endpoint linking	Link a mock to an existing endpoint (auto-fills path/method) or create a standalone mock.
Protocols	REST, SOAP (XML bodies, SOAPAction/operation matching), and GraphQL.

How generation works

Generate Mock builds example responses from each endpoint's OpenAPI/JSON schema (WSDL example XML for SOAP, a GraphQL data envelope for GraphQL). It is deterministic schema-to-example synthesis — no AI model is called and no provider key is needed — so it works fully offline. When a selected endpoint already has a mock, a conflict step lets you skip, update, or duplicate.

Static vs dynamic responses

Static responses return a fixed body exactly as written (JSON, or XML for SOAP).
Dynamic responses use {{ … }} templates resolved per request:
- Utilities: {{uuid}}, {{timestamp}}, {{date}}, {{randomInt}}, {{randomInt(N)}}, {{randomFloat}}
- Request echoes: {{request.query.name}}, {{request.headers.name}}, {{request.body.nested.path}}, {{request.path.name}}

Serving mocks: two URL styles

When the mock server runs, the UI offers two base URLs (with copy buttons):

Path-based URL — no DNS needed; use it when the engine runs on your machine or the same server.
Subdomain URL — for a centralized engine where your company has DNS. Ask your admin if unsure.

A How to Use panel provides ready-to-copy snippets for calling your mocks.

When to use mocks

The real API is not available, unstable, or still in development.
You need deterministic negative or edge cases that are hard to reproduce live.
You want faster CI or isolated workflows without environment flakiness.

Best practices

Keep mock bodies realistic and aligned with your contract so tests stay meaningful.
Use clear mock names and descriptions so the list stays scannable.
Deactivate or remove mocks when you intentionally want tests to hit the real API — only active mocks are served.

Understanding Mocks